Transmitting method, receiving method, transmitting device, and receiving device

ABSTRACT

A transmitting method includes: inputting, per unit time, a plurality of transfer packets less than or equal to a predetermined number; and transmitting, per the unit time, the plurality of transfer packets that have been input, in a state where definitions compliant with a receiving buffer model are satisfied. Each of the plurality of transfer packets includes a variable-length packet header and a variable-length payload. The definitions compliant with the receiving buffer model are predetermined for guaranteeing a buffering operation of a receiving device, and specify converting a first packet into a second packet and outputting the second packet from a buffer of the receiving device at a predetermined extraction rate. The first packet is included in the transfer packets received and includes a variable-length packet header and a variable-length payload. The second packet has a fixed-length packet header that is extended.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a U.S. continuation application of PCT InternationalPatent Application Number PCT/JP2016/003475 filed on Jul. 27, 2016,claiming the benefit of priority of Japanese Patent Application Number2016-138054 filed on Jul. 12, 2016, and U.S. Provisional Application No.62/200,294 filed on Aug. 3, 2015, the entire content of which is herebyincorporated by reference.

BACKGROUND 1. Technical Field

The present disclosure relates to a transmitting method, a receivingmethod, a transmitting device, and a receiving device.

2. Description of the Related Art

As broadcasting and communication services are sophisticated,introduction of super-high definition moving image content such as 8K(7680×4320 pixels: also referred to as 8K4K) and 4K (3840×2160 pixels:also referred to as 4K2K) has been studied. A receiving device needs todecode and display encoded data of the received ultra-high definitionmoving image in real time. A processing load of a moving image of aresolution such as 8K is great during decoding, and it is difficult todecode such a moving image in real time by using one decoder. Hence, amethod for reducing a processing load of one decoder by parallelizingdecoding processing by using a plurality of decoders, and achievingprocessing in real time has been studied.

Further, encoded data is multiplexed based on a multiplexing method suchas MPEG-2 TS (Transport Stream) or MMT (MPEG Media Transport), and istransmitted. For example, Information technology—High efficiency codingand media delivery in heterogeneous environment—Part1: MPEG mediatransport (MMT), ISO/IEC DIS 23008-1) discloses a technique oftransmitting encoded media data per packet according to MMT.

SUMMARY

As the broadcasting and communication services have advanced, anintroduction of moving image content of super-high definition such as 8Kand 4K (3840×2160 pixels) has been considered. Under the multiplexingscheme such as MPEG Media Transport (MMT) and MPEG-DASH, media data suchas video, audio, and files are multiplexed into ISO based media fileformat (ISOBMFF) (MP4 files) and then transferred using a broadcastingtransmission line or a communication transmission line after having beenMMT packetized.

However, with the MMT transfer, it might be difficult to ensure thebuffering operation of the receiving device.

The present disclosure provides a transmission method and others withwhich the buffering operation of the receiving device can be guaranteedin the case of data transfer using a scheme such as MMT.

A transmitting method according to one aspect of the present disclosureis a transmitting method including: inputting, per unit time, aplurality of transfer packets less than or equal to a predeterminednumber; and transmitting, per the unit time, the plurality of transferpackets that have been input, in a state where definitions compliantwith a receiving buffer model are satisfied, the definitions beingpredetermined for guaranteeing a buffering operation of a receivingdevice. Each of the plurality of transfer packets includes avariable-length packet header and a variable-length payload, and thedefinitions compliant with the receiving buffer model specify convertinga first packet into a second packet and outputting the second packetfrom a buffer of the receiving device at a predetermined extractionrate. The first packet is included in the plurality of transfer packetsreceived by the receiving device and includes a variable-length packetheader and a variable length payload. The second packet has afixed-length packet header that is extended.

A receiving method according to one aspect of the present disclosure isa receiving method including: receiving a plurality of transfer packetseach including a variable-length packet header and a variable-lengthpayload; converting a first packet into a second packet using a buffer,the first packet being included in the plurality of transfer packetsreceived and including a variable-length packet header and avariable-length payload, the second packet having a fixed-length packetheader that is extended; and outputting the second packet from thebuffer at a predetermined extraction rate. A size of the buffer islarger than maximum buffer occupancy calculated using a transfer rate ofthe plurality of transfer packets, an average packet length of thetransfer packets, and the predetermined extraction rate.

In addition, these overall or specific aspects may be realized by asystem, a device, an integrated circuit, a computer program or acomputer-readable recording medium such as a CD-ROM, and may be realizedby an arbitrary combination of the system, the device, the integratedcircuit, the computer program and the recording medium.

According to the present disclosure, the buffering operation of thereceiving device can be guaranteed in the case of data transfer using ascheme such as MMT.

Other advantages and/or effects according to one aspect of the presentdisclosure will become readily apparent from the following detaileddescription and the accompanying drawings. Such advantages and/oreffects are respectively provided by the features described in severalembodiments as well as in the description and drawings. However, not allof the advantages and/or effects need to be provided in order to attainone or more of the same features.

BRIEF DESCRIPTION OF DRAWINGS

These and other objects, advantages and features of the disclosure willbecome apparent from the following description thereof taken inconjunction with the accompanying drawings that illustrate a specificembodiment of the present disclosure.

FIG. 1 is a view illustrating an example where a picture is divided intoslice segments;

FIG. 2 is a view illustrating an example of a PES (Packetized ElementaryStream) packet train in which picture data is stored;

FIG. 3 is a view illustrating a picture division example according to afirst exemplary embodiment;

FIG. 4 is a view illustrating a picture division example according to acomparative example of the first exemplary embodiment;

FIG. 5 is a view illustrating an example of data of an access unitaccording to the first exemplary embodiment;

FIG. 6 is a block diagram of a transmitting device according to thefirst exemplary embodiment;

FIG. 7 is a block diagram of a receiving device according to the firstexemplary embodiment;

FIG. 8 is a view illustrating an example of an MMT packet according tothe first exemplary embodiment;

FIG. 9 is a view illustrating another example of the MMT packetaccording to the first exemplary embodiment;

FIG. 10 is a view illustrating an example of data input to each decoderaccording to the first exemplary embodiment;

FIG. 11 is a view illustrating an example of an MMT packet and headerinformation according to the first exemplary embodiment;

FIG. 12 is a view illustrating another example of data input to eachdecoder according to the first exemplary embodiment;

FIG. 13 is a view illustrating a picture division example according tothe first exemplary embodiment;

FIG. 14 is a flowchart of a transmitting method according to the firstexemplary embodiment;

FIG. 15 is a block diagram of the receiving device according to thefirst exemplary embodiment;

FIG. 16 is a flowchart of a receiving method according to the firstexemplary embodiment;

FIG. 17 is a view illustrating an example of the MMT packet and theheader information according to the first exemplary embodiment;

FIG. 18 is a view illustrating an example of the MMT packet and theheader information according to the first exemplary embodiment;

FIG. 19 is a view illustrating a configuration of an MPU (MediaProcessing Unit);

FIG. 20 is a view illustrating a configuration of MF (Movie Fragment)meta data;

FIG. 21 is a view for explaining a data transmission order;

FIG. 22 is a view illustrating an example of a method for performingdecoding without using header information;

FIG. 23 is a block diagram of a transmitting device according to asecond exemplary embodiment;

FIG. 24 is a flowchart of a transmitting method according to the secondexemplary embodiment;

FIG. 25 is a block diagram of a receiving device according to the secondexemplary embodiment;

FIG. 26 is a flowchart of an operation of specifying an MPU headposition and an NAL (Network Adaptation Layer) unit position;

FIG. 27 is a view of a flowchart of an operation of obtaininginitialization information based on a transmission order type, anddecoding media data based on the initialization information;

FIG. 28 is a flowchart of an operation of the receiving device in thecase where low delay presentation mode is provided;

FIG. 29 is a view illustrating an example of an MMT packet transmissionorder in the case where auxiliary data is transmitted;

FIG. 30 is a view for explaining an example where the transmittingdevice generates auxiliary data based on a configuration of moof;

FIG. 31 is a view for explaining reception of auxiliary data;

FIG. 32 is a flowchart of a receiving operation using auxiliary data;

FIG. 33 is a view illustrating a configuration of an MPU configured by aplurality of movie fragments;

FIG. 34 is a view for explaining an MMT packet transmission order in acase where the MPU configured as in FIG. 33 is transmitted;

FIG. 35 is a first view for explaining an operation example of thereceiving device in a case where one MPU is configured by a plurality ofmovie fragments;

FIG. 36 is a second view for explaining an operation example of thereceiving device in a case where one MPU is configured by a plurality ofmovie fragments;

FIG. 37 is a flowchart of an operation of a receiving method describedwith reference to FIGS. 35 and 36;

FIG. 38 is a view illustrating that non-VCL (Video Coding Layer) NALunits are individual data units and are aggregated;

FIG. 39 is a view illustrating that non-VCL NAL units are collectivelyused as data units;

FIG. 40 is a flowchart of an operation of the receiving device in a casewhere packet loss occurs;

FIG. 41 is a flowchart of a receiving operation in a case where an MPUis divided into a plurality of movie fragments;

FIG. 42 is a view illustrating an example of a picture predictedstructure of each TemporalId in a case where temporal scalability isrealized;

FIG. 43 is a view illustrating a relationship between a decoding time(DTS) and a presentation time (PTS) of each picture in FIG. 42;

FIG. 44 is a view illustrating an example of a picture predictedstructure for which picture delay processing and reorder processing needto be performed;

FIG. 45 is a view illustrating an example where an MPU configured by anMP4 format is divided into a plurality of movie fragments, and is storedin an MMTP (MPEG Media Transport Protocol) payload and an MMTP packet;

FIG. 46 is a view for explaining a method for calculating a PTS and aDTS and matters to be considered;

FIG. 47 is a flowchart of a receiving operation in a case where a DTS iscalculated by using DTS calculation information;

FIG. 48 is a view for explaining a method for storing a data unit in apayload according to MMT;

FIG. 49 is a flowchart of an operation of a transmitting deviceaccording to a third exemplary embodiment;

FIG. 50 is a flowchart of an operation of a receiving device accordingto the third exemplary embodiment;

FIG. 51 is a view illustrating a specific configuration example of thetransmitting device according to the third exemplary embodiment;

FIG. 52 is a view illustrating a specific configuration example of thereceiving device according to the third exemplary embodiment;

FIG. 53 is a view illustrating a method for storing a non-timed mediumin an MPU, and a method for transmitting an MMTP packet;

FIG. 54 is a view illustrating an example where each of a plurality ofitems of divided data obtained by dividing a file is packetized and istransmitted;

FIG. 55 is a view illustrating another example where each of a pluralityof items of divided data obtained by dividing a file is packetized andis transmitted;

FIG. 56 is a view illustrating a syntax of a loop per file in an assetmanagement table;

FIG. 57 is a flowchart of an operation of specifying a divided datanumber in the receiving device;

FIG. 58 is a flowchart of an operation of specifying a number of itemsof divided data in the receiving device;

FIG. 59 is a flowchart of an operation of determining whether or not tooperate fragment counters in the transmitting device;

FIG. 60 is a view for explaining a method for specifying the number ofitems of divided data and divided data numbers (in the case where thefragment counters are used);

FIG. 61 is a flowchart of an operation of the transmitting device in thecase where the fragment counters are used;

FIG. 62 is a flowchart of an operation of the receiving device in thecase where the fragment counters are used;

FIG. 63 is a view illustrating a service configuration in the case wherean identical program is transmitted by a plurality of IP data flows;

FIG. 64 is a view illustrating a specific configuration example of thetransmitting device;

FIG. 65 is a view illustrating a specific configuration example of thereceiving device.

FIG. 66 is a flowchart of an operation example of the transmittingdevice; and

FIG. 67 is a flowchart of an operation example of the receiving device.

FIG. 68 is a view illustrating a receiving buffer model in the casewhere, for example, a broadcast channel is used based on a receivingbuffer model defined according to ARIB STD B-60;

FIG. 69 is a view illustrating an example where a plurality of dataunits is aggregated and is stored in one payload;

FIG. 70 is a view illustrating an example where a plurality of dataunits is aggregated and is stored in one payload, and illustrating anexample where a video signal of an NAL size format is one data unit;

FIG. 71 is a view illustrating a configuration of a payload of an MMTPpacket which does not indicate a data unit length;

FIG. 72 is a view illustrating an extend area allocated in packet units;

FIG. 73 is a view illustrating a flowchart of an operation of thereceiving device;

FIG. 74 is a view illustrating a specific configuration example of thetransmitting device;

FIG. 75 is a view illustrating a specific configuration example of thereceiving device;

FIG. 76 is a view illustrating a flowchart of an operation of thetransmitting device;

FIG. 77 is a view illustrating a flowchart of an operation of thereceiving device;

FIG. 78 is a diagram showing a protocol stack under the MMT/TLV schemedefined according to the ARIB STD-B60;

FIG. 79 is a diagram showing a structure of a TLV packet;

FIG. 80 is a diagram showing an example of a block diagram of thereceiving device;

FIG. 81 illustrates a structure of a transfer slot;

FIG. 82 illustrates a transfer frame and one TLV stream (TLV packettrain) having specific information tlv_stream_id stored in the transferframe;

FIG. 83 is a flowchart illustrating a transmitting method in the casewhere a size of a TLV packet buffer and a maximum packet count pertransfer frame are defined;

FIG. 84 illustrates an example of a specific configuration of thetransmitting device;

FIG. 85 illustrates an example of a specific configuration of thereceiving device;

FIG. 86 is a flowchart illustrating an operation performed by thetransmitting device; and

FIG. 87 is a flowchart illustrating an operation performed by thereceiving device.

DETAILED DESCRIPTION OF THE EMBODIMENTS

A transmitting method according to one aspect of the present disclosureis a transmitting method including: inputting, per unit time, aplurality of transfer packets less than or equal to a predeterminednumber; and transmitting, per the unit time, the plurality of transferpackets that have been input, in a state where definitions compliantwith a receiving buffer model are satisfied, the definitions beingpredetermined for guaranteeing a buffering operation of a receivingdevice. Each of the plurality of transfer packets includes avariable-length packet header and a variable-length payload, and thedefinitions compliant with the receiving buffer model specify convertinga first packet into a second packet and outputting the second packetfrom a buffer of the receiving device at a predetermined extractionrate. The first packet is included in the plurality of transfer packetsreceived by the receiving device and includes a variable-length packetheader and a variable length payload. The second packet has afixed-length packet header that is extended.

With such transmitting device, the buffering operation of the receivingdevice can be guaranteed in the case of data transfer using a schemesuch as MMT.

For example, the transmitting method may further include: storing, perpredetermined data unit, the plurality of transfer packets that havebeen input. The unit time may be one of a plurality of unit transferperiods which are consecutive and do not overlap with one another, andthe plurality of transfer packets to be transmitted may be in thepredetermined data units used in the storing.

For example, the predetermined number may be a value that is setaccording to a transfer rate per the predetermined data unit and mayvary according to the transfer rate.

For example, the plurality of transfer packets that have been input mayinclude: a first transfer packet storing an actual packet different froman invalid packet; and a second transfer packet storing the invalidpacket. The storing may include: counting, as a first packet count, thefirst transfer packets when storing the first transfer packet into thepredetermined data unit; and counting, as a second packet count, aninteger value obtained by dividing a packet size of the second transferpacket by a maximum value of a packet size of the first transfer packet,when storing the second transfer packet into the predetermined dataunit. A sum of the first packet count and the second packet count may beless than or equal to the predetermined number.

For example, the invalid packet may be a NULL packet.

For example, the maximum value of the packet size of the first transferpacket may be 1500 bytes.

For example, the predetermined data unit may be a transfer frame, andeach of the plurality of unit transfer periods may correspond to alength of the transfer frame.

For example, the predetermined number may be a value that is set toprevent the transfer packets having a minimum packet size from beingconsecutive to one another.

A receiving method according to one aspect of the present disclosure isa receiving method including: receiving a plurality of transfer packetseach including a variable-length packet header and a variable-lengthpayload; converting a first packet into a second packet using a buffer,the first packet being included in the plurality of transfer packetsreceived and including a variable-length packet header and avariable-length payload, the second packet having a fixed-length packetheader that is extended; and outputting the second packet from thebuffer at a predetermined extraction rate. A size of the buffer islarger than maximum buffer occupancy calculated using a transfer rate ofthe plurality of transfer packets, an average packet length of thetransfer packets, and the predetermined extraction rate.

Note that these comprehensive or specific aspects may be realized by asystem, a device, an integrated circuit, a computer program or acomputer-readable recording medium such as a CD-ROM, and may be realizedby an arbitrary combination of the system, the device, the integratedcircuit, the computer program and the recording medium.

Exemplary embodiments will be specifically described below withreference to the drawings.

In addition, the exemplary embodiments described below are each acomprehensive or specific example. Numerical values, shapes, materials,components, placement positions and connection modes of the components,steps and a step order described in the following exemplary embodimentsare exemplary, and by no means limit the present disclosure. Further,components which are not recited in the independent claims representingthe uppermost generic concepts among components in the followingexemplary embodiments will be described as arbitrary components.

(Underlying Knowledge Forming Basis of the Present Disclosure)

In recent years, more displays of TVs, smart phones and table terminalshave higher resolutions. For example, broadcast in Japan schedules aservice for 8K4K (a resolution is 8K×4K) in 2020. A single decode hasdifficulty in decoding a moving image of a ultra-high resolution such as8K4K in real time. Therefore, a method for performing decodingprocessing in parallel by using a plurality of decoders has beenstudied.

Encoded data is multiplexed based on a multiplexing method such asMPEG-2 TS or MMT and transmitted. Therefore, a receiving device needs todemultiplex encoded data of a moving image from multiplexed data.Processing of demultiplexing encoded data from multiplexed data will bereferred to as demultiplexing.

It is necessary to sort decoding target encoded data to each decoder toparallelize decoding processing. It is necessary to analyze the encodeddata to sort the encoded data, a bit rate of content such as 8K is veryhigh, and therefore a processing load related to the analysis is great.Therefore, the following phenomenon has occurred: demultiplexingprocessing is a bottleneck and it is thus difficult to perform playbackin real time.

By the way, according to moving image encoding methods such as H.264 andH.265 standardized by MPEG and ITU (International TelecommunicationUnion), a transmitting device can divide a picture into a plurality ofareas called slices or slice segments, and encode the areas such thatthe divided areas can be independently decoded. Hence, in the case ofH.265, for example, a receiving device which receives a broadcast canparallelize decoding processing by demultiplexing data of each slicesegment from received data, and outputting data of each slice segment todifferent decoders.

FIG. 1 is a view illustrating an example where one picture is dividedinto four slice segments according to HEVC (High Efficiency VideoCoding). For example, a receiving device includes four decoders, andeach decoder decodes one of four slice segments.

According to a conventional broadcast, a transmitting device stores onepicture (an access unit according to MPEG system standards) in one PESpacket, and multiplexes a PES packet on a TS packet train. Hence, thereceiving device needs to demultiplex each slice segment bydemultiplexing a payload of the PES packet and analyzing data of theaccess unit stored in the payload, and output data of each demultiplexedslice segment to each decoder.

However, the inventors of the present invention found that the followingphenomenon occurs: a processing amount for analyzing the data of theaccess unit and demultiplexing slice segments is great and therefore itis difficult to perform this processing in real time.

FIG. 2 is a view illustrating an example where data of a picture dividedinto slice segments is stored in a payload of a PES packet.

As illustrated in FIG. 2, for example, items of data of a plurality ofslice segments (slice segments 1 to 4) are stored in a payload of onePES packet. Further, the PES packet is multiplexed on a TS packet train.

First Exemplary Embodiment

A case where H.265 is used as a moving image encoding method will bedescribed below as an example. However, the present exemplary embodimentis applicable to a case where another encoding method such as H.264 isused, too.

FIG. 3 is a view illustrating an example where an access unit (picture)according to the present embodiment is divided in division units. Theaccess unit is equally divided into two in horizontal and verticaldirections by a function called a tile introduced by H.265, and isdivided into four tiles in total. Further, each slice segment and eachtile are associated on a one-to-one basis.

A reason for equally dividing an access unit into two in the horizontaland vertical directions will be described. First, during generaldecoding, a line memory which stores data of one horizontal line isnecessary. However, in the case of an ultra-high resolution such as8K4K, a horizontal direction size increases, and therefore a line memorysize increases. It is desirable to reduce the line memory size forimplementation on the receiving device. It is necessary to divide anaccess unit in the vertical direction to reduce a line memory size. Adata structure which is a tile is necessary to perform division in thevertical direction. For these reasons, tiles are used.

Meanwhile, general images have a high correlation in the horizontaldirection, and therefore when a reference can be made in a wide range inthe horizontal direction, encoding efficiency improves. Therefore, it isdesirable to divide an access unit in the horizontal direction from aviewpoint of encoding efficiency.

By equally dividing an access unit into two in the horizontal andvertical directions, it is possible to realize both of these twocharacteristics, and take into account both of mounting and encodingefficiency. When a single decoder can decode a 4K2K moving image in realtime, the receiving device can decode 8K4K images in real time byequally dividing an 8K4K image into four, and dividing each slicesegment to realize 4K2K.

Next, a reason for associating each tile obtained by dividing an accessunit in the horizontal and vertical directions, and each slice segmenton a one-to-one basis will be described. According to 11.265, an accessunit is configured by units called a plurality of NAL (NetworkAdaptation Layer) units.

In a payload of each NAL unit, one of an access unit delimiterindicating a start position of the access unit, an SPS (Step SequenceParameter Set) which is initialization information which is commonlyused in sequence units during decoding, a PPS (Picture Parameter Set)which is initialization information which is commonly used in a pictureduring decoding, SEI (Step Supplemental Enhancement Information) whichis unnecessary for decoding processing yet is necessary to process anddisplay a decoding result, and encoded data of each slice segment isstored. A header of each NAL unit includes type information foridentifying data to be stored in a payload.

In this regard, the transmitting device can set a basic unit to an NALunit when encoded data is multiplexed in a multiplexing format such asMPEG-2 TS, MMT (MPEG Media Transport), MPEG DASH (Dynamic AdaptiveStreaming over HTTP) or RTP (Real-time Transport Protocol). In order tostore one slice segment in one NAL unit, it is desirable to divide anaccess unit in slice segment units when the access unit is divided intoareas. For this reason, the transmitting device associates each tile andeach slice segment on one-to-one basis.

In addition, as illustrated in FIG. 4, the transmitting device can alsocollectively set tile 1 to tile 4 to one slice segment. However, in thiscase, all tiles are stored in one NAL unit, and the receiving device hasdifficulty in demultiplexing the tiles in a multiplexing layer.

In addition, slice segments include independent slice segments which canbe independently decoded, and reference slice segments which refer tothe independent slice segments. Hereinafter, a case where theindependent slice segments are used will be described.

FIG. 5 is a view illustrating an example of data of an access unitdivided such that boundaries of tiles and slice segments match as shownin FIG. 3. The data of the access unit includes an NAL unit in which anaccess unit delimiter disposed at a head is stored, NAL units of an SPS,a PPS and SEI which are subsequently disposed, and data of slicesegments in which items of data of subsequently disposed tile 1 to tile4 are stored. In addition, data of the access unit may not include partor all of NAL units of an SPS, a PPS and SEI.

Next, a configuration of transmitting device 100 according to thepresent exemplary embodiment will be described. FIG. 6 is a blockdiagram illustrating a configuration example of transmitting device 100according to the present exemplary embodiment. This transmitting device100 includes encoder 101, multiplexer 102, modulator 103 and transmitter104.

Encoder 101 generates encoded data by encoding an input image accordingto H.265, for example. Further, as illustrated in, for example, FIG. 3,encoder 101 divides an access unit into four slice segments (tiles), andencodes each slice segment.

Multiplexer 102 multiplexes the encoded data generated by encoder 101.Modulator 103 modulates the data obtained by the multiplexing.Transmitter 104 transmits the modulated data as a broadcast signal.

Next, a configuration of receiving device 200 according to the presentembodiment will be described. FIG. 7 is a block diagram illustrating aconfiguration example of receiving device 200 according to the presentexemplary embodiment. This receiving device 200 includes tuner 201,demodulator 202, demultiplexer 203, a plurality of decoders 204A and204D and display 205.

Tuner 201 receives a broadcast signal. Demodulator 202 demodulates thereceived broadcast signal. The demodulated data is input todemultiplexer 203.

Demultiplexer 203 demultiplexes the demodulated data in division units,and outputs the data of each division unit to decoders 204A to 204D. Inthis regard, the division units refer to division areas obtained bydividing an access unit, and are, for example, slice segments accordingto 11.265. Further, an 8K4K image is divided into four 4K2K images.Therefore, there are four decoders 204A to 204D.

A plurality of decoders 204A to 204D operates in synchronization witheach other based on a predetermined reference clock. Each decoderdecodes encoded data in each division unit according to a DTS (DecodingTime Stamp) of the access unit, and outputs a decoding result to display205.

Display 205 generates an 8K4K output image by integrating a plurality ofdecoding results output from a plurality of decoders 204A to 204D.Display 205 displays the generated output image according to a PTS(Presentation Time Stamp) of an additionally obtained access unit. Inaddition, display 205 may perform filtering processing such as deblockfiltering to make a tile boundary indistinctive in a boundary area ofneighboring division units when integrating decoding results.

In addition, an example of transmitting device 100 and receiving device200 which transmit and receive broadcast content has been describedabove. However, content may be transmitted and received via acommunication network. When receiving device 200 receives content viathe communication network, receiving device 200 demultiplexesmultiplexed data from IP packets received from a network such as theEthernet (registered trademark).

A broadcast has a fixed channel delay caused until a broadcast signalarrives at receiving device 200 after being transmitted. Meanwhile, dueto an influence of congestion in a communication network such as theInternet, a channel delay caused until data transmitted from a serverarrives at receiving device 200 is not fixed. Hence, receiving device200 does not usually perform strict synchronization and playback basedon a reference clock such as a PCR (Program Clock Reference) accordingto MPEG-2 TS for a broadcast. Hence, receiving device 200 may cause thedisplay to display an 8K4K output image according to the PTS withoutstrictly synchronizing each decoder.

Further, due to communication network congestion, decoding processingfor all division units is not finished at a time indicated by a PTS ofan access unit in some cases. In this case, receiving device 200 skipsdisplaying the access unit or finishes decoding at least four divisionunits, and delays the display of the access unit until generation of the8K4K image is finished.

In addition, content may be transmitted and received by usingbroadcasting and communication in combination. Further, this method isapplicable to play back multiplexed data stored in a recording mediumsuch as a hard disk or a memory.

Next, a method for multiplexing access units divided into slice segmentswhen MMT is used for a multiplexing method will be described.

FIG. 8 is a view illustrating an example where data of an access unitaccording to HEVC is packetized as an MMT packet. An SPS, a PPS and SEIdo not necessarily need to be included in an access unit, yet a casewhere an SPS, a PPS and SEI are in an access unit will be described.

NAL units such as an access unit delimiter, an SPS, a PPS and SEIdisposed before a head slice segment in the access unit are collectivelystored in MMT packet #1. Subsequent slice segments are stored indifferent MMT packets per slice segment.

In addition, as illustrated in FIG. 9, NAL units disposed before a headslice segment in an access unit may be stored in the same MMT packet asthat of the head slice segment.

Further, when an NAL unit such as End-of-Sequence or End-of-Bit streamindicating an end of a sequence or a stream is added at a tail of a lastslice segment, this NAL unit is stored in the same MMT packet as that ofthe last slice segment. In this regard, the NAL unit such asEnd-of-Sequence or End-of-Bit stream is inserted in a decoding processend point or a connection point of two streams. Therefore, desirably,receiving device 200 can easily obtain these NAL units in a multiplexinglayer. In this case, these NAL units may be stored in an MMT packetdifferent from slice segments. Consequently, receiving device 200 caneasily demultiplex these NAL units in the multiplexing layer.

In addition, TS (Transport Stream), DASH (Dynamic Adaptive Streamingover HTTP) or RTP may be used for a multiplexing method. According tothese methods, too, transmitting device 100 stores different slicesegments in different packets. Consequently, it is possible to guaranteethat receiving device 200 can demultiplex slice segments in amultiplexing layer.

When, for example, TS is used, encoded data is packetized as a PESpacket in slice segment units. When RTP is used, encoded data ispacketized as an RTP packet in slice segment units. In these cases,similar to MMT packet #1 illustrated in FIG. 8, NAL units disposedbefore slice segments, and slice segments may be separately packetized.

When TS is used, transmitting device 100 indicates units of data to bestored in a PES packet by using a data alignment descriptor. Further,DASH is a method for downloading data units in an MP4 format called asegment by HTTP, and therefore transmitting device 100 does notpacketize encoded data when performing transmission. Hence, transmittingdevice 100 may create a subsample in slice segment units and storeinformation indicating a subsample storage position in an MP4 header toenable receiving device 200 to detect slice segments in a multiplexinglayer according to MP4.

MMT packetization of slice segments will be described below in detail.

As illustrated in FIG. 8, when encoded data is packetized, items of datasuch as an SPS and a PPS which are commonly referred to during decodingof all slice segments in an access unit are stored in MMT packet #1. Inthis case, receiving device 200 couples payload data of MMT packet #1and data of each slice segment, and outputs the obtained data to thedecoders. Thus, receiving device 200 can easily generate items of datainput to the decoders by coupling payloads of a plurality of MMTpackets.

FIG. 10 is a view illustrating an example where items of data input todecoders 204A to 204D are generated from MMT packets illustrated in FIG.8. Demultiplexer 203 generates data which is necessary for decoder 204Ato decode slice segment 1 by coupling items of payload data of MMTpacket #1 and MMT packet #2. Demultiplexer 203 generates items of inputdata likewise for decoder 204B to decoder 204D, too. That is,demultiplexer 203 generates data input to decoder 204B by coupling itemsof payload data of MMT packet #1 and MMT packet #3. Demultiplexer 203generates data input to decoder 204C by coupling items of payload dataof MMT packet #1 and MMT packet #4. Demultiplexer 203 generates datainput to decoder 204D by coupling items of payload data of MMT packet #1and MMT packet #5.

In addition, demultiplexer 203 may remove NAL units such as an accessunit delimiter and SEI which are not necessary for decoding processing,from the payload data of MMT packet #1, demultiplex NAL units such as anSPS and a PPS which are necessary for decoding processing, and add theNAL units to data of slice segments.

When encoded data is packetized as illustrated in FIG. 9, demultiplexer203 outputs to first decoder 204A MMT packet #1 including the head dataof the access unit in the multiplexing layer. Further, demultiplexer 203generates data input to each of the second and subsequence decoders byanalyzing an MMT packet including head data of an access unit in amultiplexing layer, demultiplexing NAL units of an SPS and a PPS, andadding the demultiplexed NAL units of the SPS and the PPS to items ofdata of second and subsequent slice segments.

Furthermore, desirably, by using information included in the header ofthe MMT packet, receiving device 200 can identify a type of data storedin an MMT payload, and an index number of a slice segment in an accessunit in a case where the slice segment is stored in the payload. In thisregard, the data type refers to one of slice segment previous data andslice segment data. Note that NAL units disposed before a head slicesegment in an access unit will be collectively referred in this way.When units such as slice segments obtained by fragmenting an MPU arestored in an MMT packet, a mode for storing an MFU (Media Fragment Unit)is used. When this mode is used, transmitting device 100 can set, forexample, Data Unit which is a data basic unit of the MFU to a sample (adata unit according to MMT and corresponding to an access unit) or asubsample (a unit obtained by dividing a sample).

In this case, a header of the MMT packet includes a field calledFragmentation indicator, and a field called Fragment counter.

Fragmentation indicator indicates whether or not data to be stored in apayload of an MMT packet is obtained by fragmenting Data unit, andindicates whether the fragment is a head or last fragment of Data unitor a fragment which is not the head or last fragment when the fragmentis obtained by fragmenting Data unit. In other words, Fragmentationindicator included in a header of a given packet is identificationinformation indicating one of that (1) this packet is included in Dataunit which is a basic data unit, that (2) Data unit is divided into aplurality of packets and stored and the packets are head packets of Dataunit, that (3) Data unit is divided into a plurality of packets andstored and the packets are packets other than head and last packets ofData unit, and that (4) Data unit is divided into a plurality of packetsand stored and the packets are last packets of Data unit.

Fragment counter is an index number indicating which fragment of Dataunit data to be stored in an MMT packet corresponds to.

Hence, transmitting device 100 sets a sample according to MMT, to Dataunit, and sets slice segment previous data and each slice segment tofragment units of Data unit, respectively, so that receiving device 200can identify a type of data stored in a payload by using informationincluded in a header of an MMT packet. That is, demultiplexer 203 cangenerate data input to each of decoders 204A to 204D by referring to aheader of an MMT packet.

FIG. 11 is a view illustrating an example where a sample is set to Dataunit, and slice segment previous data and slice segments are packetizedas fragments of Data unit.

The slice segment previous data and the slice segments are divided intofive segments of fragment #1 to fragment #5. Each fragment is stored inan individual MMT packet. In this case, values of Fragmentationindicator and Fragment counter included in a header of the MMT packetare as illustrated in FIG. 11.

For example, Fragmentation indicator is a 2-bit value of a binary digit.Fragment indicator of MMT packet #1 which is a head of Data unit,Fragment indicator of last MMT packet #5 and Fragment indicators of MMTpacket #2 to MMT packet #4 which are in-between packets are set todifferent values. More specifically, Fragment indicator of MMT packet #1which is a head of Data unit is set to 01, Fragment indicator of lastMMT packet #5 are set to 11, and Fragment indicators of MMT packet #2 toMMT packet #4 which are in-between packets are set to 10. In addition,when Data unit includes one MMT packet, Fragment indicator is set to 00.

Further, Fragment counter is 4 which is a value obtained by subtracting1 from 5 which is a total number of fragments in MMT packet #1, valuesof subsequent packets decrease one by one in order, and the value is 0in last MMT packet #5.

Hence, receiving device 200 can identify an MMT packet in which slicesegment previous data is stored, by using one of Fragment indicator andFragment counter. Further, receiving device 200 can identify an MMTpacket in which an Nth slice segment is stored, by referring to Fragmentcounter.

A header of an MMT packet additionally includes a sequence number in anMPU of Movie Fragment to which Data unit belongs, a sequence number ofthe MPU and a sequence number in Movie Fragment of a sample to whichData unit belongs. Demultiplexer 203 can uniquely determine the sampleto which Data unit belongs by referring to these sequence numbers.

Further, demultiplexer 203 can determine an index number of a fragmentin Data unit based on Fragment counter, and, consequently, can uniquelydetermine a slice segment to be stored in the fragment even when packetloss occurs. When, for example, fragment #4 illustrated in FIG. 11cannot be obtained due to packet loss, demultiplexer 203 learns that afragment received next to fragment #3 is fragment #5, and, consequently,can output slice segment 4 stored in fragment #5 to decoder 204D, not todecoder 204C.

In addition, when a channel which is guaranteed not to cause packet lossis used, demultiplexer 203 only needs to periodically process arrivingpackets without determining a type of data stored in an MMT packet or anindex number of a slice segment by referring to a header of the MMTpacket. When, for example, an access unit is transmitted by using fiveMMT packets in total including slice segment previous data and foursslice segments, receiving device 200 can obtain the slice segmentprevious data and items of data of the four slice segments in order bydetermining the slice segment previous data of the access unit whichstarts being decoded, and then processing the received MMT packet inorder.

A modified example of packetization will be described below.

A slice segment does not need to be obtained by dividing a plane of anaccess unit in both of the horizontal direction and the verticaldirection, and, as illustrated in FIG. 1, may be obtained by dividing anaccess unit in the horizontal direction or may be obtained by dividingan access unit in the vertical direction as illustrated in FIG. 1.

Further, when an access unit is divided in the horizontal direction, itis not necessary to use tiles.

Furthermore, the number of divisions of a plane of an access unit isarbitrary and is not limited to four. In this regard, area sizes ofslice segments and tiles need to be a lower limit of encoding standardsof 11.265 or more.

Transmitting device 100 may store identification information indicatinga method for dividing a plane of an access unit, in an MMT message or aTS descriptor. For example, information indicating the numbers ofdivisions of a plane in the horizontal direction and the verticaldirection may be stored. Further, unique identification informationindicating that a plane is equally divided into two in the horizontaldirection and the vertical direction, respectively, as illustrated inFIG. 3 or that a plane is equally divided into four in the horizontaldirection as illustrated in FIG. 1 may be allocated to a dividingmethod. When, for example, an access unit is divided as illustrated inFIG. 3, identification information indicates mode 2, and, when an accessunit is divided as illustrated in FIG. 1, the identification informationindicates mode 1.

Further, information indicating a limitation of encoding conditionsrelated to a plane dividing method may be included in a multiplexinglayer. For example, information indicating that one slice segment isconfigured by one tile may be used. Further, information indicating thata reference block for motion compensation during decoding of slicesegments or tiles is limited to a slice segment or a tile at the sameposition in a screen or is limited to a block within a predeterminedrange of neighboring slice segments may be used.

Furthermore, transmitting device 100 may switch whether or not to dividean access unit into a plurality of slice segments according to aresolution of a moving image. For example, transmitting device 100 maydivide an access unit into four when a processing target moving image is8K4K without dividing a plane when a processing target moving image hasa 4K2K resolution. Defining a dividing method in advance in the case ofan 8K4K moving image enables receiving device 200 to determine whetheror not to divide a plane, and the dividing method, and to switch adecoding operation by obtaining a resolution of a moving image to bereceived.

Further, receiving device 200 can detect whether or not to divide aplane by referring to a header of an MMT packet. When, for example, anaccess unit is not divided, if Data unit of MMT is set to a sample, Dataunit is not fragmented. Hence, receiving device 200 can determine thatan access unit is not divided when a value of Fragment counter includedin the header of the MMT packet is zero. Alternatively, receiving device200 may detect whether or not the value of Fragmentation indicator is01. Receiving device 200 can determine that the access unit is notdivided when the value of Fragmentation indicator is 01.

Further, receiving device 200 can support a case where a number ofdivisions of a plane of an access unit and a number of decoders do notmatch. When, for example, receiving device 200 includes two decoders204A and 204B which can decode 8K2K encoded data in real time,demultiplexer 203 outputs to decoder 204A two of four slice segmentsconfiguring the 8K4K encoded data.

FIG. 12 is a view illustrating an operation example in a case where datapacketized as an MMT packet as illustrated in FIG. 8 is input to twodecoders 204A and 204B. In this regard, desirably, receiving device 200can directly integrate and output decoding results of decoders 204A and204B. Hence, demultiplexer 203 selects slice segments to output todecoders 204A and 204B, respectively, such that the decoding results ofdecoders 204A and 204B spatially continue.

Further, demultiplexer 203 may select a decoder to use according to aresolution or a frame rate of moving image encoded data. When, forexample, receiving device 200 includes four 4K2K decoders, and aresolution of an input image is 8K4K, receiving device 200 performsdecoding processing by using all of the four decoders. Further, when aresolution of an input image is 4K2K, receiving device 200 performsdecoding processing by using one decoder. Alternatively, even when aplane is divided into four and when 8K4K can be decoded in real time bya single decoder, demultiplexer 203 integrates all division units tooutput to one decoder.

Further, receiving device 200 may determine a decoder for use by takinginto account a frame rate. There is a case where, when, for example,receiving device 200 includes two decoders whose upper limit of a framerate which enables decoding in real time is 60 fps when a resolution is8K4K, 8K4K encoded data of 120 fps is input. In this case, when a planeis configured by four division units, similar to the example in FIG. 12,slice segment 1 and slice segment 2 are input to decoder 204A, and slicesegment 3 and slice segment 4 are input to decoders 204B. Each ofdecoders 204A and 204B can decode 8K2K encoded data (the resolution is ahalf of 8K4K) up to 120 fps in real time, and therefore these twodecoders 204A and 204B perform decoding processing.

Further, even when the resolution and the frame rate are the same, if aprofile or a level of an encoding method or an encoding method such as11.264 or H.265 is different, a processing amount is different. Hence,receiving device 200 may select a decoder to be used based on thesepieces of information. In addition, when receiving device 200 hasdifficulty in decoding all items of encoded data received by way ofbroadcasting or communication or has difficulty in decoding all slicesegments or tiles configuring an area selected by a user, receivingdevice 200 may automatically determine slice segments or tiles which canbe decoded in a processing range of a decoder. Further, receiving device200 may provide a user interface which the user uses to select an areato be decoded. In this case, receiving device 200 may display a warningmessage indicating that it is difficult to decode all areas, or maydisplay information indicating decodable areas or a number of slicesegments or tiles.

Further, the above method is applicable to a case where an MMT packet inwhich slice segments of the same encoded data are stored is transmittedand received by using a plurality of channels for broadcasting andcommunication, too.

Furthermore, transmitting device 100 may perform encoding such that anarea of each slice segment overlaps to make a boundary of a divisionunit indistinctive. In an example illustrated in FIG. 13, an 8K4Kpicture is divided into slice segments 1 to 4. Each of slice segments 1to 3 is, for example, 8K×1.1K, and slice segment 4 is 8K×1K. Further,neighboring slice segments overlap each other. By so doing, it ispossible to efficiently perform motion compensation during encoding at aboundary in the case where a picture is divided into four as indicatedby dotted lines, so that image quality at the boundary portionsimproves. Thus, it is possible to reduce deterioration of image qualityat the boundary portions.

In this case, display 205 clips an 8K×1K area from an 8K×1.1K area, andintegrates resulting areas. In addition, transmitting device 100 mayseparately transmit information which indicates whether or not slicesegments overlapping each other are encoded and indicates an overlappingrange, and which is included in a multiplexing layer or encoded data.

In addition, when tiles are used, too, the same method is applicable.

An operation flow of transmitting device 100 will be described. FIG. 14is a flowchart illustrating an operation example of transmitting device100.

First, encoder 101 divides a picture (access unit) into a plurality ofslice segments (tiles) which is a plurality of areas (step S101). Next,encoder 101 generates encoded data corresponding to each of a pluralityof slice segments by encoding a plurality of slice segments such that aplurality of slice segments can be independently decoded (step S102). Inaddition, encoder 101 may encode a plurality of slice segments by usinga single encoder or by performing parallel processing in a plurality ofencoders.

Next, multiplexer 102 stores a plurality of items of encoded datagenerated by encoder 101, in a plurality of MMT packets, and multiplexesa plurality of items of encoded data (step S103). More specifically, asillustrated in FIGS. 8 and 9, multiplexer 102 stores a plurality ofitems of encoded data in a plurality of MMT packets such that items ofencoded data corresponding to different slice segments are not stored inone MMT packet. Further, as illustrated in FIG. 8, multiplexer 102stores control information which is commonly used for all decoding unitsin a picture, in MMT packet #1 different from a plurality of MMT packets#2 to #5 in which a plurality of items of encoded data is stored. Thecontrol information includes at least one of an access unit delimiter,an SPS, a PPS and SEI.

In addition, multiplexer 102 may store the control information in thesame MMT packet as one of a plurality of MMT packets in which aplurality of items of encoded data is stored. For example, asillustrated in FIG. 9, multiplexer 102 stores control information in ahead MMT packet (MMT packet #1 in FIG. 9) of a plurality of MMT packetsin which a plurality of items of encoded data is stored.

Lastly, transmitting device 100 transmits a plurality of MMT packets.More specifically, modulator 103 modulates data obtained bymultiplexing, and transmitter 104 transmits the modulated data (stepS104).

FIG. 15 is a block diagram illustrating a configuration example ofreceiving device 200, and is a view illustrating a detailedconfiguration of demultiplexer 203 and a subsequent stage illustrated inFIG. 7. As illustrated in FIG. 15, receiving device 200 further includesdecoding commanding unit 206. Further, demultiplexer 203 includes typediscriminator 211, control information obtaining unit 212, sliceinformation obtaining unit 213 and decoded data generator 214.

An operation flow of receiving device 200 will be described below. FIG.16 is a flowchart illustrating an operation example of receiving device200. Hereinafter, an operation for one access unit will be described.When decoding processing of a plurality of access units is performed,processing of this flowchart is repeated.

First, receiving device 200 receives, for example, a plurality ofpackets (MMT packets) generated by transmitting device 100 (step S201).

Next, type discriminator 211 obtains a type of encoded data stored inthe received packet by analyzing a header of the received packet (stepS202).

Next, type discriminator 211 determines whether the data stored in thereceived packet is slice segment previous data or slice segment data,based on the type of the obtained encoded data (step S203).

When the data stored in the received packets is the slice segmentprevious data (Yes in S203), control information obtaining unit 212obtains the slice segment previous data of a processing target accessunit from a payload of the received packet, and stores the slice segmentprevious data in a memory (step S204).

Meanwhile, when the data stored in the received packet is the slicesegment data (No in step S203), receiving device 200 determines whichencoded data of an area of a plurality of areas the data stored in thereceived packet corresponds to by using header information of thereceived packets. More specifically, slice information obtaining unit213 obtains index numbers Idx of slice segments stored in the receivedpacket by analyzing the header of the received packet (step S205). Morespecifically, index numbers Idx are index numbers in Movie Fragment ofan access unit (a sample according to MMT).

In addition, the processing in this step S205 may be collectivelyperformed in step S202.

Next, decoded data generator 214 determines a decoder which decodes theslice segments (step S206). More specifically, index numbers Idx and aplurality of decoders are associated in advance, and decoded datagenerator 214 determines a decoder which is associated with index numberIdx obtained in step S205 as the decoder which decodes the slicesegments.

In addition, as described with reference to the example in FIG. 12,decoded data generator 214 may determine a decoder which decodes theslice segments based on at least one of a resolution of an access unit(picture), a method for dividing the access unit into a plurality ofslice segments (tiles) and processing performances of a plurality ofdecoders of receiving device 200. For example, decoded data generator214 determines an access unit dividing method based on an MMT message oridentification information in a descriptor such as a TS section.

Next, decoded data generator 214 generates a plurality of items of inputdata (coupled data) input to a plurality of decoders by coupling controlinformation which is included in one of a plurality of packets and iscommonly used for all decoding units in a picture, and each item of aplurality of items of encoded data of a plurality of slice segments.More specifically, decoded data generator 214 obtains slice segment datafrom a payload of the received packet. Decoded data generator 214generates data input to the decoder determined in step S206 by couplingthe slice segment previous data stored in the memory in step S204, andthe obtained slice segment data (step S207).

When data of the received packet is not last data of the access unitafter step S204 or S207 (No in step S208), processing subsequent to stepS201 is performed again. That is, the above processing is repeated untilitems of input data which correspond to a plurality of slice segmentsincluded in the access unit, and are input to a plurality of decoders204A to 204D are generated.

In addition, a timing to receive a packet is not limited to a timingillustrated in FIG. 16, and a plurality of packets may be received inadvance or successively and may be stored in the memory or the like.

Meanwhile, when the data of the received packet is the final data of theaccess unit (Yes in step S208), decoding commanding unit 206 outputs aplurality of items of input data generated in step S207, tocorresponding decoders 204A to 204D (step S209).

Next, a plurality of decoders 204A to 204D generates a plurality ofdecoded images by decoding a plurality of items of input data inparallel according to a DTS of the access unit (step S210).

Lastly, display 205 generates a display image by coupling a plurality ofdecoded images generated by a plurality of decoders 204A to 204D, anddisplays the display image according to a PTS of the access unit (stepS211).

In addition, receiving device 200 obtains a DTS and a PTS of the accessunit by analyzing payload data of an MMT packet in which headerinformation of an MPU or header information of Movie Fragment is stored.Further, receiving device 200 obtains the DTS and the PTS of the accessunit from a header of a PES packet when TS is used for a multiplexingmethod. Receiving device 200 obtains the DTS and the PTS of the accessunit from a header of an RTP packet when RTP is used for a multiplexingmethod.

Further, display 205 may perform filtering processing such as deblockfiltering on each boundary of neighboring division units whenintegrating decoding results of a plurality of decoders. In addition, afilter process is unnecessary when a decoding result of a single decoderis displayed, and therefore display 205 may switch a process accordingto whether or not to perform a filter process on each boundary ofdecoding results of a plurality of decoders. Whether or not it isnecessary to perform the filter process may be defined in advanceaccording to whether or not division is performed. Alternatively,information indicating whether or not it is necessary to performfiltering processing may be additionally stored in a multiplexing layer.Further, information such as a filter coefficient which is necessary forthe filtering processing is stored in an SPS, a PPS, SEI or a slicesegment in some cases. Decoders 204A to 204D or demultiplexer 203obtains these pieces of information by analyzing SEI, and outputs thepieces of obtained information to display 205. Display 205 performs thefiltering processing by using these pieces of information. In addition,when these pieces of information are stored in the slice segment,decoders 204A to 204D desirably obtain these pieces of information.

In addition, an example where types of data stored in fragments are twotypes of slice segment previous data and slice segments has beendescribed above. The data types may be three types or more. In thiscase, classification is performed in step S203 according to a type.

Further, transmitting device 100 may fragment slice segments when a datasize of the slice segments is large to store in an MMT packet. That is,transmitting device 100 may fragment slice segment previous data and theslice segments. In this case, when an access unit and Data unit areequally set as in the example of packetization illustrated in FIG. 11,the following phenomenon occurs.

When, for example, slice segment 1 is divided into three segments, slicesegment 1 is divided into three packets whose Fragment counter valuesare 1 to 3, and is transmitted. Further, Fragment counter values ofslice segment 2 and subsequent slice segments are 4 or more, and theFragment counter values and data stored in a payload cannot beassociated. Therefore, receiving device 200 has difficulty in specifyinga packet in which head data of the slice segments is stored, based onthe header information of an MMT packet.

In such a case, receiving device 200 may analyze data of the payload ofthe MMT packet, and specify a start position of the slice segments. Inthis regard, formats for storing NAL units in a multiplexing layeraccording to H.264 or H.265 includes two types of a format which iscalled a byte stream format for adding a start code including a specificbit sequence immediately before an NAL unit header, and a format whichis called an NAL size format for adding a field indicating an NAL unitsize.

The byte stream format is used for an MPEG-2 system and RTP. The NALsize format is used for MP4, and DASH and MMT which use MP4.

When the byte stream format is used, receiving device 200 analyzeswhether or not head data of a packet matches with a start code. When thehead data of the packet and the start code match, receiving device 200can detect whether or not data included in a packet is data of a slicesegment by obtaining an NAL unit type from a subsequent NAL unit header.

Meanwhile, in the case of the NAL size format, receiving device 200 hasdifficulty in detecting a start position of an NAL unit based on a bitsequence. Hence, receiving device 200 needs to shift a pointer byreading data according to the NAL unit size in order from a head NALunit of an access unit to obtain a start position of the NAL units.

However, when a subsample unit size is indicated in an MPU or a headerof Movie Fragment according to MMT, and the subsample corresponds toslice segment previous data or a slice segment, receiving device 200 canspecify a start position of each NAL unit based on subsample sizeinformation. Hence, transmitting device 100 may give informationindicating whether or not there is the subsample unit information in anMPU or Movie Fragment, to information such as MMT or MPT (Media TransferProtocol) obtained when receiving device 200 starts receiving data.

In addition, data of the MPU is extended based on an MP4 format. MP4includes a mode in which parameter sets such as an SPS and a PPSaccording to H.264 or H.265 can be stored as sample data, and a mode inwhich it is difficult to store the parameter sets. Further, informationfor specifying this mode is indicated as an entry name of SampleEntry.When the mode that the parameter sets can be stored is used and theparameter sets are included in a sample, receiving device 200 obtainsthe parameter sets according to the above method.

Meanwhile, when the mode in which it is difficult to store the parametersets is used, the parameter sets are stored as Decoder SpecificInformation in SampleEntry or are stored by using a parameter setstream. In this regard, the parameter set stream is not generally used,and therefore transmitting device 100 desirably stores the parametersets in Decoder Specific Information. In this case, receiving device 200obtains the parameter sets to which the access unit refers by analyzingSampleEntry transmitted as meta data of the MPU in the MMT packet or asmeta data of Movie Fragment.

When the parameter sets are stored as sample data, receiving device 200can obtain the parameter sets which are necessary for decoding byreferring to the sample data without referring to SampleEntry. In thiscase, transmitting device 100 may not store the parameter sets inSampleEntry. By so doing, transmitting device 100 can use identicalSampleEntry in different MPUs, so that it is possible to reduce aprocess load of transmitting device 100 during generation of MPUs.Further, it is possible to provide an advantage that receiving device200 does not need to refer to the parameter sets in SampleEntry.

Furthermore, transmitting device 100 may store one default parameter setin SampleEntry, and store parameter sets to which the access unitrefers, in sample data. According to conventional MP4, the parametersets are generally stored in SampleEntry, and therefore when there areno parameter sets in SampleEntry, a receiving device which stopsplayback may exist. By using the above method, it is possible to solvethis phenomenon.

Further, transmitting device 100 may store parameter sets in sample datawhen parameter sets different from default parameter sets are used.

In addition, both of the modes enable parameter sets to be stored inSampleEntry, and therefore transmitting device 100 may store theparameter sets in VisualSampleEntry and receiving device 200 may obtainparameter sets from VisualSampleEntry.

In addition, according to MMT standards, MP4 header information such asMoov and Moof is transmitted as MPU meta data or movie fragment data.However, transmitting device 100 may not necessarily transmit MPU metadata and movie fragment meta data. Further, receiving device 200 canalso determine whether or not an SPS and a PPS are stored in sample databased on whether or not service according to ARIB (Association of RadioIndustries and Businesses) standards, an asset type or an MPU meta istransmitted.

FIG. 17 is a view illustrating an example where slice segment previousdata and each slice segment are set to different Data units,respectively.

In an example illustrated in FIG. 17, data sizes of slice segmentprevious data and slice segment 1 to slice segment 4 are Length #1 toLength #5, respectively. Each field value of Fragmentation indicator,Fragment counter and Offset included in a header of an MMT packet areillustrated in FIG. 17.

In this regard, Offset is offset information indicating a bit length(offset) from a head of encoded data of a sample (an access unit or apicture) to which payload data belongs, to a head byte of the payloaddata (encoded data) included in the MMT packet. In addition, that avalue of Fragment counter starts from a value obtained by subtracting 1from a total number of fragments will be described; however, the valueof Fragment counter may start from another value.

FIG. 18 is a view illustrating an example where Data unit is fragmented.In the example illustrated in FIG. 18, slice segment 1 is divided intothree fragments, and the fragments are stored in MMT packet #2 to MMTpacket #4, respectively. In this case, too, when data sizes of thefragments are Length #2_1 to Length #2_3, each field value is asillustrated in FIG. 18.

Thus, when a data unit such as a slice segment is set to Data unit, ahead of an access unit and a head of a slice segment can be determinedas follows based on a field value of an MMT packet header.

A head of a payload in a packet in a packet whose Offset value is 0 is ahead of an access unit.

A head of a payload of a packet whose Offset value takes a valuedifferent from 0 and whose Fragmentation indicator value takes 00 or 01is a head of a slice segment.

Further, when Data unit is not fragmented and packet loss does notoccur, either, receiving device 200 can specify index numbers of slicesegments to be stored in an MMT packet based on the number of slicesegments obtained after the head of the access unit is detected.

Furthermore, even when Data unit of the slice segment previous data isfragmented, receiving device 200 can detect the heads of the access unitand the slice segment likewise.

Still further, even when packet loss occurs or even when an SPS, a PPSand SEI included in slice segment previous data are set to differentData units, receiving device 200 can specify a start position of a slicesegment or a tile in a picture (access unit) by specifying an MMT packetin which head data of a slice segment is stored based on an analysisresult of an MMT header, and then analyzing a header of the slicesegment. A processing amount of slice header analysis is small, and aprocessing load does not need to be taken into consideration.

Thus, each item of a plurality of items encoded data of a plurality ofslice segments is associated with a basic data unit (Data unit) which isa unit of data to be stored in one or more packets on a one-to-onebasis. Further, each item of a plurality of items of encoded data isstored in one or more MMT packets.

Header information of each MMT packet includes Fragmentation indicator(identification information) and Offset (offset information).

Receiving device 200 determines as a head of encoded data of each slicesegment a head of payload data included in a packet including headerinformation including Fragmentation indicator whose value is 00 or 01.More specifically, receiving device 200 determines as a head of encodeddata of each slice segment a head of payload data included in a packetincluding header information including offset whose value is not 0 andFragmentation indicator whose value is 00 or 01.

Further, in an example in FIG. 17, a head of Data unit is one of a headof an access unit and a head of a slice segment, and a value ofFragmentation indicator is 00 or 01. Furthermore, receiving device 200can also detect a head of an access unit or a head of slice segmentswithout by referring to Offset, by referring to an NAL unit type and bydetermining whether a head of Data Unit is an access unit delimiter or aslice segment.

Thus, transmitting device 100 performs packetization such that a head ofNAL units starts from a head of a payload of an MMT packet.Consequently, even when slice segment previous data is divided into aplurality of Data units, receiving device 200 can detect the access unitor the head of the slice segments by analyzing Fragmentation indicatorand the NAL unit header. An NAL unit type is in a head byte of an NALunit header. Hence, when analyzing a header portion of an MMT packet,receiving device 200 can obtain an NAL unit type by additionallyanalyzing data of one byte.

Further, as described above, when encoded data encoded to enabledivision and decoding is stored in a PES packet according to MPEG-2 TS,transmitting device 100 can use a data alignment descriptor. An exampleof a method for storing encoded data in a PES packet will be describedbelow in detail.

According to, for example, HEVC, transmitting device 100 can indicatewhich one of an access unit, a slice segment and a tile data to bestored in a PES packet corresponds to by using the data alignmentdescriptor. Alignment types according to HEVC are defined as follows.

Alignment type=8 indicates a slice segment of HEVC. Alignment type=9indicates a slice segment or an access unit of HEVC. Alignment type=12indicates a slice segment or a tile of HEVC.

Consequently, transmitting device 100 can indicate which one of theslice segment and slice segment previous data the data of the PES packetcorresponds to by, for example, using type 9. Instead of slice segments,a type indicating a slice is additionally defined, so that transmittingdevice 100 may use a type indicating a slice instead of a slice segment.

Further, a DTS and a PTS included in a header of the PES packet are setin a PES packet including head data of an access unit. Consequently,when the type is 9 and the PES packet includes a field of a DTS or aPTS, receiving device 200 can determine that the entire access unit or adivision unit of a head of the access unit is stored in the PES packet.

Further, transmitting device 100 may use a field such astransport_priority indicating a priority of a TS packet in which a PESpacket including head data of an access unit is stored to enablereceiving device 200 to distinguish data included in a packet.Furthermore, receiving device 200 may determine data included in apacket by analyzing whether or not a payload of the PES packet is anaccess unit delimiter. Still further, data_alignment_indicator of a PESpacket header indicates whether or not data is stored in the PES packetaccording to these types. It is guaranteed that, when 1 is set to thisflag (data_alignment_indicator), data stored in the PES packet conformsto the type indicated in the data alignment descriptor.

Further, transmitting device 100 may use the data alignment descriptorwhen performing PES packetization in division decodable units such asslice segments. Consequently, receiving device 200 can determine thatencoded data is packetized as a PES packet in division decodable unitswhen there is the data alignment descriptor, and can determine that theencoded data is packetized as a PES packet in units of access units whenthere is no data alignment descriptor. In addition, whendata_alignment_indicator is set to 1, and there is no data alignmentdescriptor, the MPEG-2 TS standards define that a unit of PESpacketization unit is an access unit.

Receiving device 200 can determine that encoded data is packetized as aPES packet in division decodable units when a PMT (program Map Table)includes the data alignment descriptor, and generate data input to eachdecoder based on packetized units. Further, when the PMT does notinclude the data alignment descriptor and it is determined that it isnecessary to decode encoded data in parallel based on programinformation or information of another descriptor, receiving device 200generates data input to each decoder by analyzing a slice header of aslice segment. Furthermore, when a single decoder can decode encodeddata, receiving device 200 causes the decoder to decode data of theentire access unit. In addition, when information indicating thatencoded data is configured by division decodable units such as slicesegments or tiles is additionally indicated by the descriptor of thePMT, receiving device 200 may determine whether or not encoded data canbe decoded in parallel based on an analysis result of the descriptor.

Further, a DTS and a PTS included in a header of the PES packet are setin a PES packet including head data of an access unit. Therefore, whenan access unit is divided and packetized as a PES packet, second andsubsequent PES packets do not include information indicating the DTS andthe PTS of the access unit. Hence, when decoding processing is performedin parallel, each of decoders 204A to 204D and the display 205 use theDTS and the PTS stored in the header of the PES packet including headdata of the access unit.

Second Exemplary Embodiment

A method for storing data of an NAL size format in an MP4 format-basedMPU according to MMT will be described in the second exemplaryembodiment. In addition, the method for storing data in an MPU used inMMT will be described as an example below. Such a storage method isapplicable to the same MP4 format-based DASH, too.

[Storage Method for MPU]

According to an MP4 format, a plurality of access units is collectivelystored in one MP4 file. Data of each medium is stored in one MP4 file inan MPU used for MMT, and data can include an arbitrary number of accessunits. The MPU is a unit which can be decoded alone, and thereforeaccess units are stored in the MPU in GOP (Group Of Picture) units.

FIG. 19 is a view illustrating a configuration of an MPU. An MPU head isftyp, mmpu and moov which are collectively defined as MPU meta data.Initialization information which is common between files, and an MMThint track are stored in moov.

Further, information (Step Sample duration, sample_size, andsample_composition_time_offset) which makes it possible to specifyinitialization information and each size of each sample or eachsubsample, and a presentation time (PTS) and a decoding time (DTS), anddata_offset indicating a data position are stored in moof.

Further, a plurality of access unit is stored as each sample in mdat(mdat box). Data except for samples among moof and mdat is defined asmovie fragment meta data (described as MF meta data below), and sampledata of mdat is defined as media data.

FIG. 20 is a view illustrating a configuration of MF meta data. Asillustrated in FIG. 20, the MF meta data more specifically includestype, length and data of moof box (moof), and type and length of mdatbox (mdat).

When an access unit is stored in MP4 data, there are a mode thatparameter sets such as an SPS and a PPS according to 11.264 or 11.265can be stored as sample data and a mode in which it is difficult tostore the parameter sets.

In this regard, in the mode in which it is difficult to store theparameter sets, the parameter sets are stored in Decoder SpecificInformation of SampleEntry in moov. Further, in the mode that theparameter sets can be stored, the parameter sets are included in asample.

Each of MPU meta data, MF meta data and media data is stored in an MMTpayload, and a fragment type (FT) is stored as an identifier whichenables identification of these items of data in a header of the MMTpayload. FT=0 indicates MPU meta data, FT=1 indicates MF meta data andFT=2 indicates media data.

In addition, FIG. 19 illustrates an example where MPU meta data unitsand MF meta data units are stored as data units in an MMT payload.However, units such as ftyp, mmpu, moov and moof may be stored as dataunits in the MMT payload in units of data units. Similarly, FIG. 19illustrates an example where sample units are stored as data units inthe MMT payload. However, sample units and units of NAL units mayconfigure data units, and these data units may be stored in the MMTpayload as units of data units. Units obtained by further fragmentingsuch data units may be stored in the MMT payload.

[Conventional Transmitting Method, and Phenomenon which Occurs]

Conventionally, when a plurality of access units is encapsulated in anMP4 format, and at a point of time at which all samples to be stored inMP4 are ready, moov and moof are created.

When the MP4 format is transmitted in real time by way of broadcastingand when, for example, samples to be stored in one MP4 file are GOPunits, time samples of the GOP units are accumulated and then moov andmoof are created, and therefore the encapsulation causes a delay. Suchencapsulation at the transmission side increases an End-to-End delay bya GOP unit time. Thus, it is difficult to provide service in real time,and service for viewers deteriorates when, for example, live content istransmitted.

FIG. 21 is a view for explaining a data transmission order. When MMT isapplied to broadcasting, and when MMT packets are transmitted in an MPUconfiguration order (transmitted in order of MMT packets #1, #2, #3, #4,and #5) as illustrated in (a) in FIG. 21, encapsulation causes a delayduring transmission of the MMT packets.

A method for not transmitting MPU header information such as MPU metadata and MF meta data (not transmitting packets #1 and #2 andtransmitting packets #3 to #5 in order) as illustrated in (b) in FIG. 21to prevent this delay caused by encapsulation has been proposed.Further, as illustrated in (c) in FIG. 21, a method for transmittingmedia data in advance without waiting for creation of MPU headerinformation, and transmitting the MPU header information (transmittingpackets #3 to #5, #1 and #2 in order) after transmitting the media datamay be used.

The receiving device performs decoding without using the MPU headerinformation when MPU header information is not transmitted, or thereceiving device waits for the MPU header information to be obtained,and performs decoding when the MPU header information is transmittedsubsequent to media data.

However, it is not guaranteed that conventional MP4-compliant receivingdevices perform decoding without using MPU header information. Further,when the receiving device uses a conventional transmitting method toperform decoding without using an MPU header by another process, thedecoding process becomes complicated, and it is highly likely that it isdifficult to perform decoding in real time. Furthermore, when thereceiving device waits for MPU header information to be obtained, andperforms decoding, the receiving device needs to buffer media data untilthe receiving device obtains the header information. However, a buffermodel is not defined, and decoding has not been guaranteed.

Hence, a transmitting device according to the second exemplaryembodiment transmits MPU meta data prior to media data by storing commoninformation in the MPU meta data as illustrated in (d) in FIG. 21.Further, the transmitting device according to the second exemplaryembodiment transmits, subsequent to media data, MF meta data which isgenerated with a delay. Thus, there is provided the transmitting methodor the receiving method which can guarantee that media data is decoded.

A receiving method in a case where each transmitting method is used in(a) to (d) in FIG. 21 will be described below.

According to each transmitting method illustrated in FIG. 21, first, MPUdata is configured in order by data MPU meta data, MF meta data andmedia data.

When the transmitting device transmits items of data in order of the MPUmeta data, the MF meta data and the media data as illustrated in (a) inFIG. 21 after configuring the MPU data, the receiving device can performdecoding according to one of following methods (A-1) and (A-2).

(A-1) The receiving device obtains the MPU header information (the MPUmeta data and the MF meta data), and then decodes the media data byusing the MPU header information.

(A-2) The receiving device decodes the media data without using the MPUheader information.

According to both of the methods, encapsulation causes a delay at thetransmission side. However, there is an advantage that the receivingdevice does not need to buffer the media data to obtain an MPU header.When the receiving device does not perform buffering, a memory for thebuffering does not need to be mounted, and, moreover, a buffering delaydoes not occur. Further, method (A-1) is applicable to conventionalreceiving devices, too, since decoding is performed by using MPU headerinformation.

When the transmitting device transmits the media data as illustrated in(b) in FIG. 21, the receiving device can perform decoding according tofollowing method (B-1).

(B-1) The receiving device decodes the media data without using the MPUheader information.

Further, although not illustrated, when MPU meta data is transmittedbefore media data in (b) in FIG. 21 is transmitted, it is possible toperform decoding according to following method (B-2).

(B-2) The receiving device decodes media data by using MPU meta data.

Both of above methods (B-1) and (B-2) have an advantage thatencapsulation does not cause a delay at the transmission side and it isnot necessary to buffer media data to obtain an MPU header. However,according to both of methods (B-1) and (B-2), decoding is not performedby using MPU header information, and therefore it may be necessary toperform another processing for decoding.

When the transmitting device transmits items of data in order of mediadata, MPU meta data, and MF meta data as illustrated in (c) in FIG. 21,the receiving device can perform decoding according to one of followingmethods (C-1) and (C-2).

(C-1) The receiving device obtains the MPU header information (the MPUmeta data and the MF meta data), and then decodes the media data.

(C-2) The receiving device decodes the media data without using the MPUheader information.

However, when above method (C-1) is used, it is necessary to buffer themedia data to obtain MPU header information. By contrast with this, whenabove method (C-2) is used, it is not necessary to perform buffering toobtain the MPU header information.

Further, according to both of above methods (C-1) and (C-2),encapsulation does not cause a delay at the transmission side.Furthermore, according to above (D-2) method, the MPU header informationis not used, and therefore it may be necessary to perform anotherprocess.

When the transmitting device transmits items of data in order of MPUmeta data, media data and MF meta data as illustrated in (d) in FIG. 21,the receiving device can perform decoding according to one of followingmethods (D-1) and (D-2).

(D-1) The receiving device obtains MPU meta data, then further obtainsMF meta data and subsequently decodes media data.

(D-2) The receiving device obtains the MPU meta data, and then decodesmedia data without using the MF meta data.

While, when above method (D-1) is used, it is necessary to buffer themedia data to obtain the MF meta data, it is not necessary to performbuffering to obtain the MF meta data in the case of above method (D-2).

According to above (D-2) method, decoding is not performed by using MFmeta data, and therefore it may be necessary to perform another process.

As described above, there is an advantage that, when it is possible toperform decoding by using MPU meta data and MF meta data, evenconventional MP4 receiving devices can perform decoding.

In addition, in FIG. 21, the MPU data is configured in order of the MPUmeta data, the MF meta data and the media data, and, in moof, positioninformation (offset) of each sample or each subsample is defined in moofbased on this configuration. Further, the MF meta data includes data (asize or a type of box), too, other than media data in mdat box.

Hence, when the receiving device specifies the media data based on theMF meta data, the receiving device reconfigures data in an MPU dataconfiguration order irrespectively of a data transmission order, andthen performs decoding by using the moov of the MPU meta data or moof ofthe MF meta data.

In addition, in FIG. 21, the MPU data is configured in order by the MPUmeta data, the MF meta data and the media data. However, the MPU datamay be configured in a different order from that in FIG. 21, andposition information (offset) may be defined.

For example, MPU data may be configured in order of MPU meta data, mediadata and MF meta data, and negative position information (offset) may beindicated in MF meta data. In this case, too, irrespectively of a datatransmission order, the receiving device reconfigures items of data inan MPU data configuration order at the transmission side, and thenperforms decoding by using moov or moof.

In addition, the transmitting device may signal information indicatingan MPU data configuration order, and the receiving device mayreconfigure data based on the signaled information.

As described above, as illustrated in (d) in FIG. 21, the receivingdevice receives the packetized MPU meta data, the packetized media data(sample data) and the packetized MF meta data in order. In this regard,the MPU meta data is an example of first meta data, and the MF meta datais an example of second meta data.

Next, the receiving device reconfigures the MPU data (MP4 format file)including the received MPU meta data, the received MF meta data and thereceived sample data. Further, the receiving device decodes the sampledata included in the reconfigured MPU data by using the MPU meta dataand the MF meta data. The MF meta data is meta data including data(e.g., length stored in mbox) which can be generated after thetransmission side generates sample data.

In addition, more specifically, operations of the above receiving deviceare performed by each component which composes the receiving device. Forexample, the receiving device includes a receiver which receives thedata, a reconfiguring unit which reconfigures the MPU data, and adecoder which decodes the MPU data. In addition, each of the receiver,the generator and the decoder is realized by a microcomputer, aprocessor or a dedicated circuit.

[Method for Performing Decoding without Using Header Information]

Next, a method for performing decoding without using header informationwill be described. Hereinafter, a method for performing decoding withoutusing header information in the receiving device irrespectively ofwhether or not the transmission side transmits the header informationwill be described. That is, this method is applicable to a case whereeach transmitting method described with reference to FIG. 21 is used,too. In this regard, part of decoding methods is applicable in the caseof a specific transmitting method.

FIG. 22 is a view illustrating an example of a method for performingdecoding without using header information. FIG. 22 illustrates MMTpayloads and MMT packets including media data, and does not illustrateMMT payloads and MMT packets including MPU meta data and MF meta data.Further, as described below with reference to FIG. 22, media databelonging to the same MPU is continuously transferred. Furthermore, acase where each sample is stored as media data in each payload will bedescribed as an example. In the following description of FIG. 22, an NALunit may be stored or fragmented NAL units may be stored.

The receiving device needs to first obtain initialization informationnecessary for decoding to decode media data. Further, when a medium is avideo, the receiving device needs to obtain initialization informationof each sample, specify a start position of an MPU which is a randomaccess unit and obtain start positions of a sample and an NAL unit.Furthermore, the receiving device needs to specify a decoding time (DTS)and a presentation time (PTS) of each sample.

Hence, the receiving device can perform decoding by, for example, usingthe following method without using header information. In addition, whenunits of NAL units or units obtained by fragmenting NAL units are storedin a payload, a “sample” in the following description needs to be readas “an NAL unit of a sample”.

<Random Access (=To Specify Head Sample of MPU)>

When header information is not transmitted, there are following method 1and method 2 to enable the receiving device to specify a head sample ofan MPU. In addition, when header information is transmitted, method 3can be used.

[Method 1] The receiving device obtains a sample included in an MMTpacket of ‘RAP_flag=1’ in an MMT packet header.

The receiving device obtains a sample included in an MMT packet of‘RAP_flag=1’ in an MMT packet header.

[Method 2] The receiving device obtains a sample of ‘sample number=0’ inan MMT payload header.

[Method 3] When at least one of MPU meta data and MF meta data istransmitted at least before or after media data, the receiving deviceobtains a sample included in an MMT payload whose fragment type (FT) inthe MMT payload header has been switched to media data.

In addition, according to method 1 and method 2, when there is a mix ofa plurality of samples belonging to different MPUs in one payload, it isnot possible to determine which NAL unit is a random access point(RAP_flag=1 or sample number=0). Hence, it is necessary to set alimitation that samples of different MPUs are not mixed in one payload,or a limitation that, when samples of different MPUs are mixed in onepayload, and in addition, a last (or first) sample is a random accesspoint, RAP_flag is 1.

Further, the receiving device needs to shift a pointer by reading dataaccording to the NAL unit size in order from a head NAL unit of a sampleto obtain a start position of the NAL unit.

When data is fragmented, the receiving device can specify a data unit byreferring to fragment_indicator or fragment_number.

<Determination of DTS of Sample>

A method for determining a DTS of a sample includes following method 1and method 2.

[Method 1] The receiving device determines a DTS of a head sample basedon a predicted structure. In this regard, according to this method, itis necessary to analyze encoded data and it is difficult to decode theencoded data in real time, and therefore next method 2 is desirable.

[Method 2] The receiving device additionally transmits a DTS of a headsample, and obtains a DTS of the transmitted head sample. Transmittingmethods for transmitting a DTS of a head sample include, for example, amethod for transmitting a DTS of an MPU head sample by using MMT-SI(MMT-Signaling Information), and a method for transmitting a DTS of eachsample by using an MMT packet header extended area. In addition, the DTSmay be an absolute value or a relative value with respect to a PTS.Further, signaling whether or not a DTS of the head sample is includedin the transmission side may be performed.

In addition, according to both of method 1 and method 2, DTSs ofsubsequent samples are calculated as a fixed frame rate.

Methods for storing a DTS of each sample in a packet header include amethod for using an extended area and, in addition, a method for storinga DTS of a sample included in an MMT packet, in an NTP (Network TimeProtocol) time stamp field of 32 bits in an MMT packet header. When itis difficult to express the DTS by a number of bits (32 bits) of onepacket header, the DTS may be expressed by using a plurality of packetheaders. Further, the DTS may be expressed by a combination of an NTPtime stamp field and an extended area of a packet header. When DTSinformation is not included, a known value (e.g. ALLO) is used.

<Determination of PTS of Sample>

The receiving device obtains a PTS of a head sample from an MPU timestamp descriptor of each asset included in an MPU. The receiving devicecalculates PTSs of subsequent samples from parameters indicating asample display order such as a POC (Proof Of Concept) assuming a fixedframe rate. Thus, to calculate a DTS and a PTS without using headerinformation, it is necessary to perform transmission at a fixed framerate.

Further, when MF meta data is transmitted, the receiving device cancalculate absolute values of a DTS and a PTS based on relative timeinformation of the DTS or the PTS of the head sample indicated in the MFmeta data, and an absolute value of a time stamp of an MPU head sampleindicated in an MPU time stamp descriptor.

In addition, when a DTS and a PTS are calculated by analyzing encodeddata, the receiving device may calculate the DTS and the PTS by usingSEI information included in an access unit.

<Initialization Information (Parameter Sets)>

[In the case of Video]

In the case of a video, parameter sets are stored in sample data.Further, it is guaranteed that, when MPU meta data and MF meta data arenot transmitted, it is possible to obtain necessary parameter sets fordecoding by referring to sample data.

Further, as illustrated in (a) and (d) in FIG. 21, it may be definedthat, when MPU meta data is transmitted prior to media data, parametersets are not stored in SampleEntry. In this case, the receiving devicerefers to the parameter sets in a sample without referring to theparameter sets of SampleEntry.

Further, when MPU meta data is transmitted prior to media data,parameter sets which are common between MPUs and default parameter setsare stored in SampleEntry, and the receiving device may refer toparameter sets of Sample Entry and parameter sets in a sample. Theparameter sets are stored in SampleEntry, so that even conventionalreceiving devices has difficulty in performing decoding when there areno parameter sets in SampleEntry.

[In the case of Audio]

In the case of an audio, an LATM (Low Overhead Audio TransportMultiplex) header is necessary for decoding, and, according to MP4, anLATM header needs to be included in a sample entry. However, when headerinformation is not transmitted, it is difficult for the receiving deviceto obtain an LATM header, and therefore the LATM header is additionallyincluded in control information such as SI. In addition, an LATM headermay be included in a message, a table or a descriptor. In addition, anLATM header is included in a sample in some cases.

The receiving device obtains the LATM header from the SI before startingdecoding, and starts decoding an audio. Alternatively, as illustrated in(a) and (d) in FIG. 21, when MPU meta data is transmitted prior to mediadata, the receiving device can receive an LATM header prior to the mediadata. Consequently, when the MPU meta data is transmitted prior to themedia data, it is possible to perform decoding even by usingconventional receiving devices.

<Others>

A transmission order or a transmission order type may be notified as anMMT packet header, a payload header, an MPT or control information suchas another table, a message or a descriptor. In addition, thetransmission order type described herein is, for example, four types oftransmission orders in (a) to (d) in FIG. 21, and needs to be stored ina location from which each identifier for identifying each type can beobtained before decoding starts.

Further, for the transmission order types, different types between anaudio and a video may be used, or common types between an audio and avideo may be used. More specifically, for example, an audio istransmitted in order of MPU meta data, MF meta data, and media data asillustrated in (a) in FIG. 21, and a video may be transmitted in orderof MPU meta data, media data and MF meta data as illustrated in (d) inFIG. 21.

According to the above-described method, the receiving device canperform decoding without using header information. Further, when MPUmeta data is transmitted prior to media data ((a) and (d) in FIG. 21),even conventional receiving devices can perform decoding.

For example, when MF meta data is transmitted subsequent to media data((d) in FIG. 21), encapsulation does not cause a delay and evenconventional receiving devices can perform decoding.

[Configuration and Operation of Transmitting Device]

Next, a configuration and an operation of the transmitting device willbe described. FIG. 23 is a block diagram illustrating the transmittingdevice according to a second exemplary embodiment, and FIG. 24 is aflowchart illustrating a transmitting method according to the secondexemplary embodiment.

As illustrated in FIG. 23, transmitting device 15 includes encoder 16,multiplexer 17 and transmitter 18.

Encoder 16 generates encoded data by encoding an encoding target videoor audio according to, for example, H.265 (step S10).

Multiplexer 17 multiplexes (packetizes) the encoded data generated byencoder 16 (step S11). More specifically, multiplexer 17 packetizes eachof sample data, MPU meta data and MF meta data configuring an MP4 formatfile. The sample data is data obtained by encoding a video signal or anaudio signal, the MPU meta data is an example of first meta data and theMF meta data is an example of second meta data. The first meta data andthe second meta data are each meta data used for decoding sample data,and differ in that the second meta data includes data which can begenerated after the sample data is generated.

In this regard, the data which can be generated after the sample data isgenerated is, for example, data other than the sample data which isstored in mdat of an MP4 format (data in a header of mdat, i.e., typeand length illustrated in FIG. 20). In this regard, the second meta datamay include length which is at least part of this data.

Transmitter 18 transmits the packetized MP4 format file (step S12).Transmitter 18 transmits the MP4 format file according to, for example,the method illustrated in (d) in FIG. 21. That is, transmitter 18transmits the packetized MPU meta data, the packetized sample data andthe packetized MF meta data in this order.

In addition, each of encoder 16, multiplexer 17 and transmitter 18 isrealized by a microcomputer, a processor or a dedicated circuit.

[Configuration of Receiving Device]

Next, a configuration and an operation of the receiving device will bedescribed. FIG. 25 is a block diagram illustrating the receiving deviceaccording to the second exemplary embodiment.

As illustrated in FIG. 25, receiving device 20 includes packet filter21, transmission order type discriminator 22, random access unit 23,control information obtaining unit 24, data obtaining unit 25, PTS/DTScalculator 26, initialization information obtaining unit 27, decodingcommanding unit 28, decoder 29 and presenting unit 30.

[Operation 1 of Receiving Device]

First, an operation of specifying an MPU head position and an NAL unitposition in receiving device 20 in a case where a medium is a video willbe described. FIG. 26 is a flowchart illustrating such an operation ofreceiving device 20. In addition, an MPU data transmission order type isstored in SI information by transmitting device 15 (multiplexer 17).

First, packet filter 21 packet-filters a received file. Transmissionorder type discriminator 22 analyzes SI information obtained by thepacket filtering, and obtains the MPU data transmission order type (stepS21).

Next, transmission order type discriminator 22 determines(discriminates) whether or not the packet-filtered data includes MPUheader information (at least one of MPU meta data or MF meta data) (stepS22). When the data includes the MPU header information (Yes in stepS22), random access unit 23 specifies an MPU head sample by detecting aswitch of a fragment type of an MMT payload header to media data (stepS23).

Meanwhile, when the data does not include the MPU header information (Noin step S22), random access unit 23 specifies an MPU head sample basedon RAP_flag of the MMT packet header or sample number of an MMT payloadheader (step S24).

Further, transmission order type discriminator 22 determines whether ornot the packet-filtered data includes MF meta data (step S25). When itis determined that the data includes the MF data (Yes in step S25), dataobtaining unit 25 obtains an NAL unit by the reading NAL unit based onan offset of a sample or a subsample and size information included inthe MF meta data (step S26). Meanwhile, when it is determined that thedata does not include the MF meta data (No in step S25), data obtainingunit 25 obtains an NAL unit by reading data of an NAL unit size in orderfrom a head NAL unit of the sample (step S27).

In addition, even when it is determined in step S22 that the dataincludes the MPU header information, receiving device 20 may specify anMPU head sample by using the processing in step S24 instead of step S23.Further, when it is determined that the data includes the MPU headerinformation, the processing in step S23 and the processing in step S24may be used in combination.

Furthermore, even when it is determined in step S25 that the dataincludes the MF meta data, receiving device 20 may obtain an NAL unit byusing the processing in step S27 without using the processing in stepS26. Still further, when it is determined that the data includes the MFmeta data, the processing in step S26 and the processing in step S27 maybe used in combination.

Further, it is assumed that it is determined in step S25 that the dataincludes MF meta data and the MF meta data is transmitted subsequent tothe media data. In this case, receiving device 20 may buffer the mediadata, waits for the MF meta data to be obtained and then perform theprocess in step S26 or receiving device 20 may determine whether or notto perform the process in step S27 without waiting for the MF meta datato be obtained.

For example, receiving device 20 may determine whether or not to waitfor the MF meta data to be obtained based on whether or not receivingdevice 20 includes a buffer of a buffer size which can buffer the mediadata. Further, receiving device 20 may determine whether or not to waitfor the MF meta data to be obtained based on whether or not anEnd-to-End delay becomes little. Furthermore, receiving device 20 mayperform decoding processing by mainly using the processing in step S26,and use the processing in step S27 in a processing mode in a case wherepacket loss occurs.

In addition, in the case of a predetermined transmission order type,step S22 and step S26 may be skipped, and, in this case, receivingdevice 20 may determine a method for specifying an MPU head sample and amethod for specifying an NAL unit by taking into account a buffer sizeor an End-to-End delay.

In addition, when a transmission order type is known in advance,receiving device 20 does not need transmission order type discriminator22.

Further, although not illustrated with reference to FIG. 26, decodingcommanding unit 28 outputs to decoder 29 data obtained by the dataobtaining unit based on a PTS and a DTS calculated by PTS/DTS calculator26 and initialization information obtained by initialization informationobtaining unit 27. Decoder 29 decodes the data, and presenting unit 30presents the decoded data.

[Operation 2 of Receiving Device]

Next, an operation of obtaining initialization information based on atransmission order type, and decoding media data based on initializationinformation in receiving device 20 will be described. FIG. 27 is aflowchart illustrating such an operation.

First, packet filter 21 packet-filters a received file. Transmissionorder type discriminator 22 analyzes SI information obtained by thepacket filtering, and obtains a transmission order type (step S301).

Next, transmission order type discriminator 22 determines whether or notMPU meta data has been transmitted (step S302). When it is determinedthat the MPU meta data has been transmitted (Yes in step S302),transmission order type discriminator 22 determines whether or not theMPU meta data has been transmitted prior to the media data as a resultof analysis in step S301 (step S303).

In a case where the MPU meta data has been transmitted prior to themedia data (Yes in step S303), initialization information obtaining unit27 decodes the media data based on common initialization informationincluded in the MPU meta data and initialization information of sampledata (step S304).

Meanwhile, when it is determined that the MPU meta data has beentransmitted subsequent to the media data (No in step S303), dataobtaining unit 25 buffers the media data until the MPU meta data isobtained (step S305), and performs the processing in step S304 after theMPU meta data is obtained.

Further, when it is determined in step S302 that the MPU meta data hasnot been transmitted (No in step S302), initialization informationobtaining unit 27 decodes the media data based on the initializationinformation of the sample data (step S306).

In addition, when it is guaranteed that the transmission side can decodethe media data only when the decoding is based on the initializationinformation of the sample data, the processing in step S306 is usedwithout performing processing based on the determination in step S302and step S303.

Further, receiving device 20 may determine whether or not to buffer themedia data before step S305. In this case, receiving device 20 moves tothe processing in step S305 when determining to buffer the media data,and moves to the processing in step S306 when determining not to bufferthe media data. Whether or not to buffer the media data may be performedbased on a buffer size and an occupied amount of receiving device 20 ormay be determined by taking into account an End-to-End delay by, forexample, selecting a less End-to-End delay.

[Operation 3 of Receiving Device]

Hereinafter, a transmitting method and a receiving method in a casewhere MF meta data is transmitted subsequent to media data ((c) and (d)in FIG. 21) will be described in detail. Hereinafter, a case of (d) inFIG. 21 will be described as an example. In addition, the method in (d)in FIG. 21 is used for transmission, and a transmission order type isnot signaled.

As described above, when items of data are transmitted in order of MPUmeta data, media data and MF meta data as illustrated in (d) in FIG. 21,

(D-1) Receiving device 20 obtains the MPU meta data, then furtherobtains the MF meta data and subsequently decodes the media data.]

(D-2) Receiving device 20 obtains the MPU meta data, and then decodesthe media data without using the MF meta data.

The above two decoding methods are provided.

In this regard, according to D-1, it is necessary to buffer the mediadata to obtain the MF meta data; however, the conventional MP4-compliantreceiving devices can perform decoding by using MPU header information.Further, according to D-2, it is not necessary to buffer the media datato obtain the MF meta data; however, it is difficult to perform decodingby using the MF meta data, and therefore it is necessary to performanother processing for decoding.

Further, according to the method in (d) in FIG. 21, the MF meta data istransmitted subsequent to the media data, and therefore it is possibleto provide an advantage that encapsulation does not cause a delay and itis possible to reduce an End-to-End delay.

Receiving device 20 can select the above two types of decoding methodsaccording to performance of receiving device 20 and service qualityprovided by receiving device 20.

Transmitting device 15 needs to guarantee that it is possible to reduceoccurrence of an overflow or an underflow of a buffer and performdecoding in a decoding operation of receiving device 20. For an elementwhich defines a decoder model for performing decoding by using methodD-1, the following parameter can be used, for instance.

-   -   Buffer size (MPU buffer) for reconfiguring MPU

For example, buffer size=maximum rate×maximum MPU time×α holds, and themaximum rate is upper limit rate of profile and level of encodeddata+overhead of MPU header. Further, a maximum MPU time is a maximumtime length of a GOP in the case of 1 MPU=1 GOP (video).

In this regard, the audio may be a GOP unit which is common betweenvideos, or may be another unit. α represents a margin for not causing anoverflow, and may be multiplied on or added to maximum rate×maximum MPUtime. In the case of multiplication, α≥1 holds, and, in the case ofaddition, α≥0 holds.

-   -   An upper limit of a decoding delay time until data is decoded        after the data is input to the MPU buffer (TSTD_delay in STD        (System Target Decoder) of MPEG-TS).

For example, during transmission, a DTS is set such that obtainingcompletion time of MPU data in receiver <=DTS holds, by taking intoaccount a maximum MPU time and an upper limit value of a decoding delaytime.

Further, transmitting device 15 may allocate a DTS and a PTS accordingto a decoder model for performing decoding by using method D-1. Thus,transmitting device 15 may guarantee decoding for the receiving devicewhich performs decoding by using method D-1, and transmit auxiliaryinformation which is necessary to perform decoding by using method D-2.

For example, transmitting device 15 can guarantee an operation of thereceiving device which performs decoding by using method D-2 bysignaling a pre-buffering time in a decoder buffer when performingdecoding by using method D-2.

The pre-buffering time may be included in SI control information such asa message, a table or a descriptor, or may be included in a header of anMMT packet or an MMT payload. Further, SEI in encoded data may beoverwritten. A DTS and a PTS for performing decoding by using method D-1may be stored in an MPU time stamp descriptor and SampleEntry, and a DTSand a PTS for performing decoding by using method D-2 or a pre-bufferingtime may be described in SEI.

Receiving device 20 may select decoding method D-1 when receiving device20 supports an MP4-compliant decoding operation which uses an MPUheader, and may select one of methods D-1 and D-2 when receiving device20 supports both of the methods D-1 and D-2.

Transmitting device 15 may allocate a DTS and a PTS to guarantee onedecoding operation (D-1 in this description), and further transmitauxiliary information for assisting the one decoding operation.

Further, End-to-End delay in method D-2 is likely to be great due to adelay caused by pre-buffering of MF meta data compared to that in methodD-1. Hence, receiving device 20 may select method D-2 and performdecoding to reduce an End-to-End delay. For example, receiving device 20may use method D-2 to reduce an End-to-End delay. Further, receivingdevice 20 may use method D-2 when operating in a low delay presentationmode for presenting live content, channel selection or a zappingoperation with a low delay.

FIG. 28 is a flowchart illustrating such a receiving method.

First, receiving device 20 receives an MMT packet, and obtains MPU data(step S401). Further, receiving device 20 (transmission order typediscriminator 22) determines whether or not to present the program inthe low delay presentation mode (step S402).

When not presenting the program in the low delay presentation mode (Noin step S402), receiving device 20 (random access unit 23 andinitialization information obtaining unit 27) makes a random access unitby using header information and obtains initialization information (stepS405). Further, receiving device 20 (PTS/DTS calculator 26, decodingcommanding unit 28, decoder 29 and presenting unit 30) performs decodingand presentation processing based on a PTS and a DTS allocated by atransmission side (step S406).

Meanwhile, when presenting the program in the low delay presentationmode (Yes in step S402), receiving device 20 (random access unit 23 andinitialization information obtaining unit 27) makes a random access byusing a decoding method which does not use header information, andobtains initialization information (step S403). Further, receivingdevice 20 performs decoding and the presentation processing based onauxiliary information for performing decoding without using a PTS and aDTS allocated by the transmission side and header information (stepS404). In addition, in step S403 and step S404, processing may beperformed by using MPU meta data.

[Transmitting and Receiving Methods Using Auxiliary Data]

The transmitting and receiving operations in a case where MF meta datais transmitted subsequent to media data ((c) and (d) in FIG. 21) will bedescribed above. Next, a method for enabling transmitting device 15 tostart decoding earlier by transmitting auxiliary data including afunction of part of MF meta data and to reduce an End-to-End delay willbe described. Hereinafter, an example where auxiliary data is furthertransmitted based on the transmitting method illustrated in (d) in FIG.21 will be described. However, a method using auxiliary data is appliedto the transmitting methods illustrated in (a) to (c) in FIG. 21.

(a) in FIG. 29 is a view illustrating an MMT packet transmitted by usingthe method illustrated in (d) in FIG. 21. That is, items of data aretransmitted in order of MPU meta data, media data and MF meta data.

In this regard, sample #1, sample #2, sample #3 and sample #4 aresamples included in the media data. In addition, an example where mediadata is stored in sample units in an MMT packet will be described. Themedia data may be stored in units of NAL units in an MMT packet or maybe stored in units obtained by dividing an NAL unit. In addition, aplurality of NAL units is aggregated and is stored in an MMT packet insome cases.

As described above with reference to method D-1, in the case of themethod illustrated in (d) in FIG. 21, i.e., when items of data aretransmitted in order of MPU meta data, media data and MF meta data, theMPU meta data is obtained, then the MF meta data is further obtained andthen the media data is decoded. According to such method D-1, it isnecessary to buffer the media data for obtaining the MF meta data;however, decoding is performed by using MPU header information.Consequently, method D-1 is applicable to conventional MP4-compliantreceiving devices, too. Meanwhile, receiving device 20 needs to wait fordecoding to start until MF meta data is obtained.

By contrast with this, as illustrated in (b) in FIG. 29, according to amethod using auxiliary data, auxiliary data is transmitted prior to MFmeta data.

MF meta data includes DTSs or PTSs of all samples included in a moviefragment, and information indicating an offset and a size. By contrastwith this, auxiliary data includes DTSs or PTSs of part of samples amongsamples included in a movie fragment, and information indicating anoffset and a size.

For example, while MF meta data includes information of all samples(sample #1 to sample #4), auxiliary data includes information of part ofsamples (samples #1 and #2).

In a case illustrated in (b) in FIG. 29, sample #1 and sample #2 can bedecoded by using the auxiliary data, so that an End-to-End delay islittle compared to transmitting method D-1. In addition, information ofsamples may be combined in any way and may be included in the auxiliarydata or the auxiliary data may be repeatedly transmitted.

For example, as illustrated in (c) in FIG. 29, transmitting device 15imparts information of sample #1 to the auxiliary information whentransmitting the auxiliary information at timing A, and imparts piecesof information of sample #1 and sample #2 to the auxiliary informationwhen transmitting the auxiliary information at timing B. Whentransmitting the auxiliary information at timing C, transmitting device15 imparts pieces of information of sample #1, sample #2 and sample #3to the auxiliary information.

In addition, MF meta data includes pieces of information of sample #1,sample #2, sample #3 and sample #4 (information of all samples in amovie fragment).

The auxiliary data does not necessarily need to be immediatelytransmitted after being generated.

In addition, a type indicating that the auxiliary data is stored isspecified in a header of an MMT packet or an MMT payload.

When, for example, auxiliary data is stored in an MMT payload by usingan MPU mode, a data type indicating auxiliary data is specified as afragment type field value (e.g. FT=3). The auxiliary data may be databased on a configuration of moof, or employ another configuration.

When the auxiliary data is stored as a control signal (a descriptor, atable and a message) in an MMT payload, a descriptor tag, a table ID anda message ID indicating the auxiliary data are specified.

Further, a PTS or a DTS may be stored in a header of an MMT packet or anMMT payload.

[Generation Example of Auxiliary Data]

An example where the transmitting device generates auxiliary data basedon a configuration of moof will be described below. FIG. 30 is a viewfor explaining an example where the transmitting device generatesauxiliary data based on a configuration of moof.

According to general MP4, as illustrated in FIG. 20, moof is created foreach movie fragment. moof includes a DTS or a PTS of a sample includedin each movie fragment, and information indicating an offset or a size.

In this regard, transmitting device 15 configures MP4 (MP4 file) byusing part of items of sample data among items of sample dataconfiguring an MPU, and generates auxiliary data.

As illustrated in, for example, (a) in FIG. 30, transmitting device 15generates MP4 by using sample #1 among samples #1 to #4 configuring anMPU, and uses a header of moof+mdat as auxiliary data.

Next, as illustrated in (b) in FIG. 30, transmitting device 15 generatesMP4 by using sample #1 and sample #2 among samples #1 to #4 configuringthe MPU, and a header of moof+mdat as next auxiliary data.

Next, as illustrated in (c) in FIG. 30, transmitting device 15 generatesMP4 by using sample #1, sample #2 and sample #3 among samples #1 to #4configuring the MPU, and a header of moof+mdat as next auxiliary data.

Next, as illustrated in (d) in FIG. 30, transmitting device 15 generatesMP4 by using all samples among samples #1 to #4 configuring an MPU, anduses a header of moof+mdat as movie fragment meta data.

In addition, transmitting device 15 generates auxiliary data per sample,yet may generate auxiliary data per N sample. A value of N is anarbitrary numeral, and, when, for example, one MPU is transmitted andauxiliary data is transmitted M times, N=all samples/M may hold.

In addition, information indicating an offset of a sample in moof maytake an offset value after a sample entry area of a number of subsequentsamples is secured as a NULL area.

In addition, auxiliary data may be generated to fragment MF meta data.

[Example of Receiving Operation Using Auxiliary Data]

Reception of auxiliary data generated as described with reference toFIG. 30 will be described. FIG. 31 is a view for explaining reception ofauxiliary data. In addition, in (a) in FIG. 31, the number of samplesconfiguring an MPU is 30, and auxiliary data is generated per 10 sampleand transmitted.

In (a) in FIG. 30, auxiliary data #1 includes samples #1 to #10,auxiliary data #2 includes samples #1 to #20, and MF meta data includespieces of sample information of samples #1 to #30.

In addition, samples #1 to #10, samples #11 to #20 and samples #21 to#30 are stored in one MMT payload, however, may be stored in sampleunits or NAL units or may be stored in fragmented or aggregated units.

Receiving device 20 receives packets of an MPU meta, a sample, an MFmeta and auxiliary data.

Receiving device 20 couples items of sample data in a reception order(to a tail of each sample), receives the latest auxiliary data and thenupdates the items of auxiliary data so far. Further, receiving device 20can configure a complete MPU by lastly replacing auxiliary data with MFmeta data.

At a point of time at which auxiliary data #1 is received, receivingdevice 20 couples the items of data as in an upper stage in (b) in FIG.31, and configures MP4. Consequently, receiving device 20 can parsesamples #1 to #10 by using MPU meta data and information of auxiliarydata #1, and perform decoding based on information of a PTS, a DTS, anoffset and a size included in the auxiliary data.

Further, at a point of time at which auxiliary data #2 is received,receiving device 20 couples the items of data as in a middle stage in(b) in FIG. 31, and configures MP4. Consequently, receiving device 20can parse samples #1 to #20 by using MPU meta data and information ofauxiliary data #2, and perform decoding based on information of a PTS, aDTS, an offset and a size included in the auxiliary data.

Further, at a point of time at which MF meta data is received, receivingdevice 20 couples the items of data as in a lower stage in (b) in FIG.31, and configures MP4. Consequently, receiving device 20 can parsesamples #1 to #30 by using MPU meta data and MF meta data, and performdecoding based on information of a PTS, a DTS and an offset, a sizeincluded in the MF meta data.

When there is no auxiliary data, receiving device 20 can obtain piecesof information of samples for the first time after reception of MF metadata, and therefore needs to start decoding after receiving the MF metadata. However, transmitting device 15 generates and transmits auxiliarydata, so that receiving device 20 can obtain information of samples byusing the auxiliary data without waiting for reception of MF meta dataand, consequently, can advance a decoding start time. Further,transmitting device 15 generates auxiliary data based on moof describedwith reference to FIG. 30, so that receiving device 20 can performparsing by using a parser of conventional MP4 as is.

Further, auxiliary data and MF meta data to be newly generated includepieces of information of samples which overlap those of auxiliary datatransmitted in the past. Hence, even when past auxiliary data cannot beobtained due to packet loss, it is possible to reconfigure MP4 andobtain sample information (a PTS, a DTS, a size and an offset) by usingauxiliary data and MF meta data to be newly obtained.

In addition, auxiliary data does not necessarily need to include pastsample data. For example, auxiliary data #1 may correspond to items ofsample data #1 to #10, and auxiliary data #2 may correspond to items ofsample data #11 to #20. As illustrated in, for example, (c) in FIG. 31,transmitting device 15 may successively output, as auxiliary data, unitsobtained by fragmenting data units which are complete MF meta data.

Further, for a packet loss countermeasure, transmitting device 15 mayrepeatedly transmit auxiliary data or repeatedly transmit MF meta data.

In addition, an MMT packet and an MMT payload in which auxiliary data isstored includes an MPU sequence number and an asset ID similar to MPUmeta data, MF meta data and sample data.

The above receiving operation using auxiliary data will be describedwith reference to a flowchart in FIG. 32. FIG. 32 is a flowchartillustrating the receiving operation using auxiliary data.

First, receiving device 20 receives an MMT packet, and analyzes a packetheader and a payload header (step S501). Next, receiving device 20analyzes whether a fragment type is auxiliary data or MF meta data (stepS502), and overwrites and updates past auxiliary data when the fragmenttype is the auxiliary data (step S503). In this case, when there is nopast auxiliary data of the same MPU, receiving device 20 uses receivedauxiliary data as new auxiliary data. Further, receiving device 20obtains a sample based on the MPU meta data, the auxiliary data and thesample data to decode (step S504).

Meanwhile, when the fragment type is the MF meta data, receiving device20 overwrites the MF meta data over the past auxiliary data in step S505(step S505). Further, receiving device 20 obtains a sample in a completeMPU form based on the MPU meta data, the MF meta data and the sampledata, for performing decoding (step S506).

In addition, although not illustrated in FIG. 32, in step S502,receiving device 20 stores data in the buffer when the fragment type isMPU meta data, and stores data coupled to a tail of each sample in thebuffer when the fragment type is sample data.

When auxiliary data cannot be obtained due to packet loss, receivingdevice 20 can overwrite latest auxiliary data over auxiliary data, ordecode a sample by using past auxiliary data.

In addition, a transmission cycle and a number of times of transmissionsof auxiliary data may take predetermined values. Information of thetransmission cycle and the number of times of transmissions (count orcount down) may be transmitted together with data. For example, atransmission cycle, the number of times of transmissions, and a timestamp such as initial_cpb_removal_delay may be stored in a data unitheader.

By transmitting auxiliary data including information of a first sampleof an MPU prior to initial_cpb_removal_delay once or more, it ispossible to conform to a CPB (Coded Picture Buffer) buffer model. Inthis case, in an MPU time stamp descriptor, a value based on picturetiming SEI is stored.

In addition, a transmitting method for such a receiving operation usingsuch auxiliary data is not limited to an MMT method, and is applicableto MPEG-DASH in a case where packets configured by an ISOBMFF (ISO basemedia file format) file format are transmitted by way of streaming.

[Transmitting Method in the case where One MPU is Configured by aPlurality of Movie Fragments]

A case where one MPU is configured by one movie fragment has beendescribed above with reference to FIG. 19 and subsequent figures.Hereinafter, a case where one MPU is configured by a plurality of moviefragments will be described. FIG. 33 is a view illustrating aconfiguration of an MPU configured by a plurality of movie fragments.

In FIG. 33, samples (#1 to #6) stored in one MPU are sorted and storedin two movie fragments. A first movie fragment is generated based onsamples #1 to #3, and a corresponding moof box is generated. A secondmovie fragment is generated based on samples #4 to #6, and acorresponding moof box is generated.

Headers of the moof box and the mdat box in the first movie fragment arestored as movie fragment meta data #1 in an MMT payload and an MMTpacket. Meanwhile, headers of the moof box and the mdat box in thesecond movie fragment are stored as movie fragment meta data #2 in anMMT payload and an MMT packet. In addition, in FIG. 33, hatching isapplied to MMT payloads in which items of movie fragment meta data arestored.

In addition, the number of samples configuring an MPU and the number ofsamples configuring a movie fragment are arbitrary. For example, thenumber of samples configuring an MPU is defined as the number of samplesin GOP units, and the number of samples which is half the GOP units isdefined as a movie fragment, so that two movie fragments may beconfigured.

In addition, an example where one MPU includes two movie fragments (themoof box and the mdat box) will be described hereinafter. However, anumber of movie fragments included in one MPU may not be two and may bethree or more. Further, the number of samples to be stored in a moviefragment may not be equally divided, and may be divided to an arbitrarynumber of samples.

In addition, in FIG. 33, MPU meta data units and MF meta data units arestored as data units in an MMT payload. However, transmitting device 15may store units such as ftyp, mmpu, moov and moof as data units in anMMT payload in units of data units, or in an MMT payload in unitsobtained by fragmenting the data units. Further, transmitting device 15may store data units in an MMT payload in units obtained by aggregatingthe data units.

Furthermore, in FIG. 33, samples are stored in an MMT payload in sampleunits. However, transmitting device 15 may configure data units in unitsof NAL units or units obtained by aggregating a plurality of NAL unitsinstead of sample units, and store the data units in an MMT payload inthe units of the data units. Further, transmitting device 15 may storedata units in an MMT payload in units obtained by fragmenting the dataunits or may store the data units in an MMT payload in units obtained byaggregating the data units.

In addition, in FIG. 33, an MPU is configured in order of moof #1, mdat#1, moof #2 and mdat #2, and offset is allocated to moof #1 assumingthat corresponding mdat #1 is allocated subsequent to moof #1. However,offset may be allocated assuming that mdat #1 is allocated prior to moof#1. In this regard, in this case, movie fragment meta data cannot begenerated in a form of moof+mdat, and headers of moof and mdat areseparately transmitted.

Next, an MMT packet transmission order in a case where the MPUconfigured described with reference to FIG. 33 is transmitted will bedescribed. FIG. 34 is a view for explaining an MMT packet transmissionorder.

(a) in FIG. 34 illustrates a transmission order in a case where MMTpackets are transmitted in an MPU configuration order illustrated inFIG. 33. (a) in FIG. 34 specifically illustrates an example where an MPUmeta, MF meta #1, media data #1 (samples #1 to #3), MF meta #2 and mediadata #2 (samples #4 to #6) are transmitted in this order.

(b) in FIG. 34 illustrates an example where an MPU meta, media data #1(samples #1 to #3), MF meta #1, media data #2 (samples #4 to #6) and MFmeta #2 are transmitted in this order.

(c) in FIG. 34 illustrates an example where media data #1 (samples #1 to#3), an MPU meta, MF meta #1, media data #2 (samples #4 to #6) and MFmeta #2 are transmitted in this order.

MF meta #1 is generated by using samples #1 to #3, and MF meta #2 isgenerated by using samples #4 to #6. Hence, when the transmitting methodin (a) in FIG. 34 is used, encapsulation causes a delay duringtransmission of sample data.

By contrast with this, when the transmitting methods in (b) and (c) inFIG. 34 are used, it is possible to transmit samples without waiting forgeneration of an MF meta. Consequently, encapsulation does not cause adelay and it is possible to reduce an End-to-End delay.

Further, according to the transmission order in (a) in FIG. 34, one MPUis divided into a plurality of movie fragments and the number of samplesto be stored in an MF meta is small compared to that in FIG. 19.Consequently, it is possible to reduce a delay amount caused byencapsulation compared to that in FIG. 19.

In addition to the methods described herein, transmitting device 15 maycouple MF meta #1 and MF meta #2 to collectively transmit at the last ofan MPU. In this case, MF metas of different movie fragments may beaggregated and stored in one MMT payload. Further, MF metas of differentMPUs may be collectively aggregated and stored in an MMT payload.

[Receiving Method in a Case where One MPU is Configured by a Pluralityof Movie Fragments]

Hereinafter, an operation example of receiving device 20 of receivingand decoding MMT packets transmitted in the transmission order describedwith reference to (b) in FIG. 34 will be described. FIGS. 35 and 36 areviews for explaining a such operation example.

Receiving device 20 receives each MMT packet including an MPU meta,samples and MF metas in a transmission order illustrated in FIG. 35.Sample data is coupled in a reception order.

Receiving device 20 couples items of data as illustrated in (1) in FIG.36 at T1 which is a time at which MF meta #1 is received, and configuresMP4. Consequently, receiving device 20 can obtain samples #1 to #3 basedon MPU meta data and information of MF meta #1, and perform decodingbased on information of a PTS, a DTS, an offset and a size included inthe MF meta.

Further, receiving device 20 couples items of data as illustrated in (2)in FIG. 36 at T2 which is a time at which MF meta #2 is received, andconfigures MP4. Consequently, receiving device 20 can obtain samples #4to #6 based on MPU meta data and information of MF meta #2, and performdecoding based on information of a PTS, a DTS, an offset and a sizeincluded in the MF meta. Further, receiving device 20 may couple itemsof data as illustrated in (3) in FIG. 36 and configure MP4, and therebyobtain samples #1 to #6 based on pieces of information of MF meta #1 andMF meta #2.

By dividing one MPU into a plurality of movie fragments, a time taken toobtain a first MF meta of the MPU is reduced, so that it is possible toadvance a decoding start time. Further, it is possible to reduce abuffer size for accumulating samples which are not yet decoded.

In addition, transmitting device 15 may set movie fragment divisionunits such that a time taken to transmit (or receive) an MF metacorresponding to a movie fragment after a first sample of the moviefragment is transmitted (or received) is shorter thaninitial_cpb_removal_delay specified by an encoder. By making suchsettings, a reception buffer can conform to a CPB buffer and realizedecoding with a low delay. In this case, it is possible to use absolutetimes based on initial_cpb_removal_delay for a PTS and a DTS.

Further, transmitting device 15 may divide a movie fragment at equalintervals or may divide subsequent movie fragments at intervals shorterthan those of previous movie fragments. Consequently, receiving device20 can receive an MF meta including information of samples without failbefore decoding the samples, and perform continuous decoding.

For a method for calculating absolute times of a PTS and a DTS, thefollowing two methods can be used.

(1) The absolute times of the PTS and the DTS are determined based on areception time (T1 or T2) of MF meta #1 or MF meta #2 and relative timesof the PTS and the DTS included in the MF meta.

(2) The absolute times of the PTS and the DTS are determined based on anabsolute time such as an MPU time stamp descriptor signaled from thetransmission side and the relative times of the PTS and the DTS includedin the MF meta.

Further, (2-A) the absolute time signaled from transmitting device 15may be an absolute time calculated based on initial_cpb_removal_delayspecified by the encoder.

Furthermore, (2-B) the absolute time signaled from transmitting device15 may be an absolute time calculated based on a prediction value of areception time of an MF meta.

In addition, MF meta #1 and MF meta #2 may be repeatedly transmitted. MFmeta #1 and MF meta #2 are repeatedly transmitted, so that receivingdevice 20 can obtain the MF meta again even when the MF meta cannot beobtained due to packet loss.

In a payload header of an MFU including a sample configuring a moviefragment, an identifier indicating a movie fragment order can be stored.Meanwhile, an identifier indicating an order of MF metas configuring amovie fragment is not included in an MMT payload. Hence, receivingdevice 20 identifies an order of MF metas according topacket_sequence_number. Alternatively, transmitting device 15 may storean identifier indicating which movie fragment an MF meta belongs to, incontrol information (a message, a table or a descriptor), an MMT header,an MMT payload header or a data unit header to signal.

In addition, transmitting device 15 may transmit an MPU meta, MF metasand samples in a predetermined transmission order determined in advance,and receiving device 20 may perform reception processing based on thepredetermined transmission order determined in advance. Further,transmitting device 15 may signal the transmission order and receivingdevice 20 may select (determine) reception processing based on thesignaling information.

The above receiving method will be described with reference to FIG. 37.FIG. 37 is a flowchart illustrating an operation of the receiving methoddescribed with reference to FIGS. 35 and 36.

First, receiving device 20 discriminates (identifies) whether dataincluded in a payload is MPU meta data, MF meta data, or sample data(MFU) according to a fragment type included in an MMT payload (stepsS601 and S602). When the data is sample data, receiving device 20buffers the sample, and waits for MF meta data corresponding to thesample to be received and start being decoded (step S603).

Meanwhile, when the data is the MF meta data in step S602, receivingdevice 20 obtains information (a PTS, a DTS, position information and asize) of the sample from the MF meta data, obtains the sample based onthe obtained sample information, and decodes and presents the samplebased on the PTS and the DTS (step S604).

In addition, although not illustrated, when the data is MPU meta data,the MPU meta data includes initialization information which is necessaryfor decoding. Hence, receiving device 20 accumulates this initializationinformation to decode sample data in step S604.

In addition, when accumulating items of received data of the MPU (MPUmeta data, MF meta data and sample data) in an accumulating device,receiving device 20 accumulates the MPU data after rearranging the itemsof data to an MPU configuration described with reference to FIG. 19 or33.

In addition, the transmission side allocates a packet sequence number ofa packet having the same packet ID to an MMT packet. In this case,packet sequence numbers may be allocated after MMT packets including MPUmeta data, MF meta data and sample data are rearranged in a transmissionorder, or packet sequence numbers may be allocated in an order before arearrangement.

When the packet sequence numbers are allocated in the order before therearrangement, receiving device 20 can rearrange items of data in an MPUconfiguration order based on the packet sequence numbers, so that theitems of data can be easily accumulated.

[Method for Detecting Head of Access Unit and Head of Slice Segment]

A method for detecting a head of an access unit and a head of a slicesegment based on an MMT packet header and information of an MMT payloadheader will be described.

In this regard, two examples of a case where non-VCL NAL units (anaccess unit delimiter, a VPS, an SPS, a PPS and SEI) are collectivelystored as data units in an MMT payload, and a case where non-VCL NALunits are used data units and the data units are aggregated and storedin one MMT payload will be described.

FIG. 38 is a view illustrating that non-VCL NAL units are individuallydefined as data units and are aggregated.

In the case of FIG. 38, the head of the access unit is an MMT packetwhose fragment_type value is an MFU, and is head data of an MMT payloadincluding a data unit whose aggregation_flag value is 1 and whose offsetvalue is 0. In this case, a Fragmentation_indicator value takes 0.

Further, in the case of FIG. 38, the head of the slice segment is an MMTpacket whose fragment_type value is an MFU, and is head data of an MMTpayload whose aggregation_flag value is 0 and whosefragmentation_indicator value is 00 or 01.

FIG. 39 is a view illustrating that non-VCL NAL units are collectivelyused as data units. In addition, a field value of a packet header is asillustrated in FIG. 17 (or FIG. 18).

In the case of FIG. 39, at a head of an access unit, head data of apayload in a packet whose Offset value is 0 is the head of the accessunit.

Further, in the case of FIG. 39, the head of the slice segment takes ishead data of a payload of a packet whose Offset value takes a valuedifferent from 0 and whose Fragmentation_indicator value is 00 or 01.

[Reception Processing in the case Where Packet Loss Occurs]

Generally, when MP4 format data is transmitted in environment in whichpacket loss occurs, receiving device 20 recovers packets by way of ALFEC(Application Layer FEC) and packet retransmission control or the like.

However, when packet loss occurs in a case where ALFEC is not used forstreaming such as broadcasting, it is difficult to recover packets.

Receiving device 20 needs to resume decoding a video or an audio afterdata is lost due to packet loss. Hence, receiving device 20 needs todetect a head of an access unit or an NAL unit, and start decoding fromthe head of the access unit or the NAL unit.

However, a start code is not allocated to the head of the MP4 format NALunit, and therefore, receiving device 20 has difficulty in detecting thehead of the access unit or the NAL unit by analyzing a stream.

FIG. 40 is a flowchart illustrating an operation of receiving device 20when packet loss occurs.

Receiving device 20 detects packet loss based on Packetsequence number,packet counter or fragment counter in a header of an MMT packet or anMMT payload (step S701), and determines which packet has been lost basedon a preceding and subsequent relationship (step S702).

When it is determined that packet loss does not occur (No in step S702),receiving device 20 configures an MP4 file, and decodes an access unitor an NAL unit (step S703).

When it is determined that packet loss occurs (Yes in step S702),receiving device 20 generates an NAL unit corresponding to an NAL unitwhose packet has been lost by using dummy data, and configures an MP4file (step S704). When inputting the dummy data in the NAL unit,receiving device 20 indicates the dummy data in an NAL unit type.

Further, receiving device 20 can resume decoding by detecting a head ofa next access unit or NAL unit and inputting head data to a decoderbased on the methods described with reference to FIGS. 17, 18, 38 and 39(step S705).

In addition, when packet loss occurs, receiving device 20 may resumedecoding from the head of the access unit or the NAL unit based oninformation detected based on a packet header, or may resume decodingfrom the head of the access unit or the NAL unit based on headerinformation of a reconfigured MP4 file including the NAL unit of thedummy data.

When accumulating MP4 files (MPU), receiving device 20 may additionallyobtain and accumulate (replace) packet data (NAL units) whose packet hasbeen lost, by way of broadcasting or communication.

In this case, when obtaining a lost packet by way of communication,receiving device 20 notifies the server of information of the lostpacket (a packet ID, an MPU sequence number, a packet sequence number,an IP data flow number and an IP address), and obtains this packet.Receiving device 20 may simultaneously obtain not only lost packets butalso a packet group prior to and subsequent to the lost packets.

[Method for Configuring Movie Fragment]

Hereinafter, a method for configuring a movie fragment will be describedin detail.

As described with reference to FIG. 33, the number of samplesconfiguring a movie fragment and the number of movie fragmentsconfiguring one MPU are arbitrary. For example, the number of samplesconfiguring a movie fragment and the number of movie fragmentsconfiguring one MPU may be fixed predetermined numbers or may bedynamically determined.

In this regard, a movie fragment is configured to satisfy the followingconditions at the transmission side (transmitting device 15), so that itis possible to guarantee low-delay decoding in receiving device 20.

The conditions are as follows.

Transmitting device 15 generates and transmits an MF meta as a moviefragment in units obtained by dividing sample data to enable receivingdevice 20 to receive the MF meta including information of arbitrarysamples without fail before a decoding time (DTS(i)) of the arbitrarysamples (Step Sample(i)).

More specifically, transmitting device 15 configures a movie fragment byusing encoded samples (including an ith sample) before DTS(i).

For a method for dynamically determining the number of samplesconfiguring a movie fragment and the number of movie fragmentsconfiguring one MPU to guarantee low-delay decoding, for example, thefollowing method is used.

(1) At a start of decoding, decoding time DTS(0) of sample Sample(0) ofa GOP head is a time based on initial_cpb_removal_delay. Thetransmitting device configures a first movie fragment by using encodedsamples at a time before DTS(0). Further, transmitting device 15generates MF meta data corresponding to the first movie fragment, andtransmits the MF meta data at a time before DTS(0).

(2) Transmitting device 15 configures a movie fragment to satisfy theabove conditions for subsequent samples.

When, for example, a head sample of a movie fragment is a kth sample, anMF meta of the movie fragment including the kth sample is transmitted bydecoding time DTS(k) of the kth sample. When an encoding completion timeof a lth sample is before DTS(k) and an encoding completion time of a(l+1)th sample is after DTS(k), transmitting device 15 configures amovie fragment by using the kth sample to the lth sample.

In addition, transmitting device 15 may configure a movie fragment byusing samples from the kth sample to a sample before the lth sample.

(3) Transmitting device 15 finishes encoding a last sample of an MPU,configures a movie fragment by using the rest of samples and generates,and transmits MF meta data corresponding to this movie fragment.

In addition, transmitting device 15 may configure a movie fragment byusing part of encoded samples without configuring a movie fragment byusing all encoded samples.

In addition, an example where the number of samples configuring a moviefragment and the number of movie fragments configuring one MPU aredynamically determined based on the above conditions to guaranteelow-delay decoding has been described above. However, the method fordetermining the number of samples and the number of movie fragments isnot limited to this. For example, the number of movie fragmentsconfiguring one MPU may be fixed to a predetermined value, and thenumber of samples may be determined to satisfy the above conditions.Further, the number of movie fragments configuring one MPU and a time atwhich the movie fragments are divided (or an encoding amount of themovie fragments) may be fixed to predetermine values, and the number ofsamples may be determined to satisfy the above conditions.

Furthermore, when an MPU is divided into a plurality of movie fragments,information indicating whether or not the MPU is divided into aplurality of movie fragments, attributes of the divided movie fragmentsor an attribute of an MF meta for the divided movie fragments may betransmitted.

In this regard, each movie fragment attribute is information indicatingwhether the movie fragment is a head movie fragment of an MPU, a lastmovie fragment of the MPU, or the other movie fragment.

Further, each MF meta attribute is information indicating whether eachMF meta indicates an MF meta corresponding to a head movie fragment ofan MPU, an MF meta corresponding to a last movie fragment of the MPU oran MF meta corresponding to the other movie fragment.

In addition, transmitting device 15 may store the number of samplesconfiguring a movie fragment and the number of movie fragmentsconfiguring one MPU as control information, and transmit the controlinformation.

[Operation of Receiving Device]

The operation of receiving device 20 based on movie fragments configuredas described will be described.

Receiving device 20 determines each absolute time of a PTS and a DTSbased on MPU time stamp descriptors such as an absolute time signaledfrom the transmission side and relative times of the PTS and the DTSincluded in an MF meta.

Receiving device 20 performs processing as follows based on attributesof divided movie fragments when an MPU is divided based on informationindicating whether or not the MPU is divided into a plurality of moviefragments.

(1) When a movie fragment is a head movie fragment of the MPU, receivingdevice 20 generates absolute times of a PTS and a DTS by using anabsolute time of the PTS of a head sample included in an MPU time stampdescriptor, and relative times of a PTS and a DTS included in the MFmeta.

(2) When the movie fragment is not a head movie fragment of the MPU,receiving device 20 generates absolute times of the PTS and the DTS byusing relative times of the PTS and the DTS included in an MF metawithout using information of the MPU time stamp descriptor.

(3) When the movie fragment is a last movie fragment of the MPU,receiving device 20 calculates the absolute times of PTSs and DTSs ofall samples and then resets processing of calculating the PTSs and theDTSs (relative time addition process). In addition, the reset processingmay be performed on the head movie fragment of the MPU.

Receiving device 20 may determine whether or not a movie fragment isdivided as described below. Further, receiving device 20 may obtainattribute information of movie fragments as follows.

For example, receiving device 20 may determine whether or not a moviefragment is divided based on an identifiermovie_fragment_sequence_number field value indicating an order of themovie fragment indicated in an MMTP (MMT Protocol) payload header.

More specifically, when the number of movie fragments included in oneMPU is 1, the movie_fragment_sequence_number field value is 1 and thereis the field value whose value is 2 or more, receiving device 20 maydetermine that the MPU is divided into a plurality of movie fragments.

Further, when the number of movie fragments included in one MPU is 1,the movie_fragment_sequence_number field value is 0 and there is thefield value whose value is other than 0, receiving device 20 maydetermine that the MPU is divided into a plurality of movie fragments.

Attribute information of the movie fragment may be also determined basedon movie_fragment_sequence_number likewise.

In addition, whether or not a movie fragment is divided and attributeinformation of the movie fragment may be determined by counting thenumber of times of transmissions of movie fragments or MF metas includedin one MPU without using movie_fragment_sequence_number.

According to the configurations of transmitting device 15 and receivingdevice 20 described above, receiving device 20 can receive moviefragment meta data at shorter intervals than that of an MPU and startlow-delay decoding. Further, it is possible to perform low-delaydecoding by using decoding processing based on an MP4 parsing method.

A receiving operation in a case where an MPU is divided into a pluralityof movie fragments as described above will be described with referenceto a flowchart. FIG. 41 is a flowchart illustrating the receivingoperation in a case where an MPU is divided into a plurality of moviefragments. In addition, this flowchart illustrates the operation in stepS604 in FIG. 37 in more detail.

First, receiving device 20 obtains MF meta data based on a data typeindicated in an MMTP payload header when the data type is an MF meta(step S801).

Next, receiving device 20 determines whether or not an MPU is dividedinto a plurality of movie fragments (step S802), and determines whetheror not the received MF meta data is head meta data of the MPU (stepS803) when the MPU is divided into a plurality of movie fragments (Yesin step S802). Receiving device 20 calculates absolute times of a PTSand a DTS based on an absolute time of the PTS indicated in an MPU timestamp descriptor and relative times of the PTS and the DTS indicated inthe MF meta data (step S804) when the received MF meta data is the headMF meta data of the MPU (Yes in step S803), and determines whether ornot the meta data is last meta data of the MPU (step S805).

Meanwhile, receiving device 20 calculates the absolute times of the PTSand the DTS by using the relative times of the PTS and the DTS indicatedin the MF meta data without using the information of the MPU time stampdescriptor (step S808) when the received MF meta data is not the head MFmeta data of the MPU (No in step S803), and moves to processing in stepS805.

When it is determined in step S805 that the MF meta data is the last MFmeta data of the MPU (Yes in step S805), receiving device 20 calculatesabsolute times of PTSs and DTSs of all samples, and then resetsprocessing of calculating the PTS and the DTS. When it is determined instep S805 that the MF meta data is not the last MF meta data of the MPU(No in step S805), receiving device 20 finishes the process.

Further, when it is determined in step S802 that the MPU is not dividedinto a plurality of movie fragments (No in step S802), receiving device20 obtains sample data based on MF meta data transmitted subsequent tothe MPU, and determines the PTS and the DTS (S807).

Furthermore, although not illustrated, receiving device 20 finallyperforms decoding processing and presentation processing based on thedetermined PTS and DTS.

[Phenomenon which Occurs when Movie Fragment is Divided, and Solution]

A method for reducing an End-to-End delay by dividing a movie fragmenthas been described so far. Hereinafter, a new phenomenon which occurswhen a movie fragment is divided, and its solution will be described.

First, a picture structure of encoded data will be described as abackground. FIG. 42 is a view illustrating an example of a picturepredicted structure for each TemporalId when temporal scalability isrealized.

According to encoding methods such as MPEG-4 AVC and HEVC (HighEfficiency Video Coding), it is possible to realize scalability(temporal scalability) in a time domain by using picture B(bidirectional reference predicted picture) which can be referred fromanother picture.

TemporalId illustrated in FIG. 42 is an identifier of a layer of anencoding structure, and TemporalId having a higher value indicates adeeper layer. Each square block indicates a picture, Ix in a blockrepresents picture I (intra-plane predicted picture), Px representspicture P (forward reference predicted picture), and Bx and bx representpictures B (bidirectional reference predicted picture). x of Ix/Px/Bxindicates a display order, and represents an order to display pictures.Each arrow between pictures indicates a reference relationship and, forexample, picture B4 indicates that a predicted image is generated byusing I0 and B8 as reference images. In this regard, using anotherpicture having a higher TemporalId than TemporalId of one picture as areference image is forbidden. Layers are defined to secure temporalscalability, and, by, for example, decoding all pictures in FIG. 42, avideo of 120 fps (frame per second) is obtained and, by decoding layerswhose TemporalIds are 0 to 3, a video of 60 fps is obtained.

FIG. 43 is a view illustrating a relationship between a decoding time(DTS) and a presentation time (PTS) of each picture in FIG. 42. Forexample, picture I0 illustrated in FIG. 43 is displayed after decodingB4 is finished so as not to produce a gap between decoding and display.

As illustrated in FIG. 43, when picture B is included in a predictedstructure, a decoding order and a display order are different.Therefore, receiving device 20 needs to perform picture delay processingand picture rearrangement (reorder) processing after decoding a picture.

An example of a picture predicted structure for securing scalability inthe time domain has been described. Even when scalability in the timedomain is not used, it is necessary to perform the picture delayprocessing and the reorder processing depending on predicted structures.FIG. 44 is a view illustrating a picture predicted structure example forwhich a picture delay process and a reorder process need to beperformed. In addition, numbers in FIG. 44 indicate a decoding order.

As illustrated in FIG. 44, depending on predicted structures, a headsample in a decoding order and a head sample in a presentation order aredifferent in some cases. In FIG. 44, the head sample in the presentationorder is a fourth sample in the decoding order. In addition, FIG. 44illustrates an example of a predicted structure, and the predictedstructure is not limited to such a structure. According to anotherpredicted structure, too, a head sample in a decoding order and a headsample in a presentation order are different in some cases.

Similar to FIG. 33, FIG. 45 is a view illustrating an example where anMPU configured by an MP4 format is divided into a plurality of moviefragments, and is stored in an MMTP payload and an MMTP packet. Inaddition, the number of samples configuring an MPU and the number ofsamples configuring a movie fragment are arbitrary. For example, thenumber of samples configuring an MPU is defined as the number of samplesin GOP units, and the number of samples which is half the GOP units isdefined as a movie fragment, so that two movie fragments may beconfigured. One sample may be one movie fragment or samples configuringan MPU may not be divided.

FIG. 45 illustrates an example where one MPU includes two moviefragments (a moof box and a mdat box). The number of movie fragmentsincluded in one MPU may not be two. The number of movie fragmentsincluded in one MPU may be three or more or may be the number of samplesincluded in the MPU. Further, the number of samples to be stored in amovie fragment may not be an equally divided number of samples, and maybe divided to an arbitrary number of samples.

Movie fragment meta data (MF meta data) includes information of a PTS, aDTS, an offset and a size of a sample included in a movie fragment, andreceiving device 20 extracts the PTS and the DTS from the MF metaincluding the information of the sample and determines a decoding timingand a presentation timing when decoding the sample.

Hereinafter, for more detailed description, an absolute value of adecoding time of sample i is described as DTS(i), and an absolute timeof a presentation time is described as PTS(i).

Information of the ith sample of time stamp information stored in moofof an MF meta is more specifically relative values of decoding times ofthe ith sample and (i+1)th sample and relative values of the decodingtime and a presentation time of the ith sample which will be referred toas DT(i) and CT(i) below.

Movie fragment meta data #1 includes DT(i) and CT(i) of samples #1 to#3, and movie fragment meta data #2 includes DT(i) and CT(i) of samples#4 to #6.

Further, an absolute value of a PTS of a head access unit of an MPU isstored in an MPU time stamp descriptor, and receiving device 20calculates a PTS and a DTS based on PTS_MPU of the head access unit ofthe MPU, a CT and a DT.

FIG. 46 is a view for explaining a method for calculating a PTS and aDTS in a case where samples #1 to #10 configure an MPU, and a phenomenonwhich occurs.

(a) in FIG. 46 illustrates an example where an MPU is not divided intomovie fragments. (b) in FIG. 46 illustrates an example where an MPU isdivided into two movie fragments in five sample units. (c) in FIG. 46illustrates an example where an MPU is divided into ten movie fragmentsin sample units.

As described with reference to FIG. 45, when a PTS and a DTS arecalculated by using an MPU time stamp descriptor and time stampinformation in MP4 (a CT and a DT), the head sample in the presentationorder in FIG. 44 is the fourth sample in the decoding order. Hence, thePTS stored in the MPU time stamp descriptor is a PTS (absolute value) ofthe fourth sample in the decoding order. In addition, hereinafter, thissample is referred to as sample A. Further, a head sample in a decodingorder is referred to as sample B.

Absolute time information related to a time stamp is information of anMPU time stamp descriptor. Therefore, receiving device 20 has difficultyin calculating PTSs (absolute times) and DTSs (absolute times) of othersamples until sample A arrives. Receiving device 20 has difficulty incalculating either a PTS or a DTS of sample B.

In an example in (a) in FIG. 46, sample A is included in the same moviefragment as that of sample B, and is stored in one MF meta.Consequently, receiving device 20 can immediately determine a DTS ofsample B after receiving the MF meta.

In an example in (b) in FIG. 46, sample A is included in the same moviefragment as that of sample B, and is stored in one MF meta.Consequently, receiving device 20 can immediately determine a DTS ofsample B after receiving the MF meta.

In an example in (c) in FIG. 46, sample A and sample B are included indifferent movie fragments. Hence, receiving device 20 has difficulty indetermining a DTS of sample B only if an MF meta including a CT and a DTof a movie fragment including sample A has been received.

Hence, in the case of the example in (c) in FIG. 46, receiving device 20has difficulty in immediately starting decoding after sample B arrives.

Thus, when a movie fragment including sample B does not include sampleA, if receiving device 20 has not received an MF meta related to a moviefragment including sample A, receiving device 20 has difficulty instarting decoding sample B.

This phenomenon occurs when a head sample in the presentation order anda head sample in the decoding order do not match, a movie fragment isdivided until sample A and sample B stop being stored in the same moviefragment. Further, the phenomenon occurs irrespectively of whether an MFmeta is transmitted earlier or later.

Thus, when the head sample in the presentation order and the head samplein the decoding order do not match, and when sample A and sample B arenot stored in the same movie fragment, it is difficult to immediatelydetermine a DTS after reception of sample B. Hence, transmitting device15 transmits additionally a DTS (absolute value) of sample B orinformation for enabling the reception side to calculate a DTS (absolutevalue) of sample B. Such information may be transmitted by using controlinformation, a packet header or the like.

Receiving device 20 calculates a DTS (absolute value) of sample B byusing such information. FIG. 47 is a flowchart illustrating a receivingoperation when a DTS is calculated by using such information.

Receiving device 20 receives a head movie fragment of an MPU (stepS901), and determines whether or not sample A and sample B are stored inthe same movie fragment (step S902). When sample A and sample B arestored in the same movie fragment (Yes in step S902), receiving device20 calculates a DTS by using information of an MF meta without using theDTS (absolute time) of sample B, and starts decoding (step S904). Inaddition, in step S904, receiving device 20 may determine a DTS by usingthe DTS of sample B.

Meanwhile, when sample A and sample B are not stored in the same moviefragment in step S902 (No in step S902), receiving device 20 obtains theDTS (absolute time) of sample B, determines the DTS and starts decoding(step S903).

In addition, an example where an absolute value of a decoding time ofeach sample and an absolute time of a presentation time are calculatedby using an MF meta (time stamp information stored in moof of an MP4format) according to MMT standards is described above. However, an MFmeta may be replaced with arbitrary control information which can beused to calculate an absolute value of a decoding time of each sampleand an absolute value of a presentation time to carry out thecalculation. Such control information includes, for example, controlinformation in which relative values CT(i) of decoding times of the ithsample and the (i+1)th sample are replaced with relative values ofpresentation times of the ith sample and the (i+1)th sample, and controlinformation including both of relative values CT(i) of decoding times ofthe ith sample and (i+1)th sample, and relative values of presentationtimes of the ith sample and the (i+1)th sample.

Third Exemplary Embodiment

[Outline]

A content transmitting method and a content data structure in the casewhere content such as a video, an audio, a caption and data broadcast istransmitted by way of broadcasting will be described in the thirdexemplary embodiment. That is, the content transmitting methodspecialized in broadcast stream playback, and the content data structurewill be described.

In addition, an example where an MMT method (referred to simply as MMTbelow) is used as a multiplexing method will be described in the thirdexemplary embodiment. However, other multiplexing methods such as DASHand RTP may be used.

First, a method for storing a data unit (DU) in a payload according toMMT will be described in detail. FIG. 48 is a view for explaining amethod for storing a data unit in a payload according to MMT.

According to MMT, a transmitting device stores part of data configuringan MPU as a data unit in an MMTP payload, adds a header to the data andtransmits the data. The header includes the MMTP payload header and anMMTP packet header. In addition, units of the data unit may be units ofNAL units or units of samples.

(a) in FIG. 48 illustrates an example where the transmitting deviceaggregates a plurality of data units to store in one payload. In theexample in (a) in FIG. 48, a data unit header (DUH) and a data unitlength (DUL) are allocated to a head of each of a plurality of dataunits, and a plurality of data units to which data unit headers and dataunit lengths are allocated is collectively stored in the payload.

(b) in FIG. 48 illustrates an example where one data unit is stored inone payload. In the example in (b) in FIG. 48, a data unit header isallocated to a head of the data unit, and the data unit is stored in thepayload. (c) in FIG. 48 illustrates an example where one data unit isdivided, data unit headers are allocated to the divided data units, andthe data units are stored in a payload.

The data unit includes types of a timed-MPU which is media such as avideo, an audio and a caption including information related tosynchronization, a non-timed-MFU which is media such as a file notincluding information related to synchronization, MPU meta data, and MFmeta data, and a data unit header is determined according to a data unittype. In addition, MPU meta data and MF meta data do not include a dataunit header.

Further, the transmitting device fundamentally has difficulty inaggregating data units of different types, yet it may be defined thatthe transmitting device can aggregate data units of different types.When, for example, an MF meta data size in the case where data isdivided into movie fragments per sample is small, it is possible toreduce a number of packets and reduce a transmission quantity byaggregating the MF meta data and media data.

When a data unit is an MFU, part of information of the MPU such asinformation for configuring the MPU (MP4) is stored as a header.

For example, a header of a timed-MFU includesmovie_fragment_sequence_number, sample_number, offset, priority anddependency_counter, and a header of a non-timed-MFU includes item_iD. Ameaning of each field is indicated by standards such as ISO/IEC23008-1or ARIB STD-B60. The meaning of each field defined in these standardswill be described below.

movie_fragment_sequence_number indicates a sequence number of a moviefragment to which the MFU belongs, and is indicated in ISO/IEC14496-12,too.

sample_number indicates a sample number to which the MFU belongs, and isindicated in ISO/IEC14496-12, too.

offset indicates byte units of an offset amount of the MFU in the sampleto which the MFU belongs.

priority indicates a relative importance of the MFU in an MPU to whichthe MFU belongs, and an MFU of a higher number of priority indicates amore important MFU than MFUs of smaller numbers of priority.

dependency_counter indicates a number of MFUs for which whether or notto perform decoding processing depends on the MFU, i.e., the number ofMFUs for which it is difficult to perform decoding processing unlessthis MFU is decoded. When, for example, the MFU is HEVC and a B pictureor a P picture refers to an I picture, it is difficult to decode the Bpicture or the P picture unless the I picture is decoded.

Hence, when the MFU is in units of samples, dependency_counter of theMFU of the I picture indicates a number of pictures which refer to the Ipicture. When the MFU is in units of NAL units, dependency_counter inthe MFU belonging to the I picture indicates a number of NAL unitsbelonging to pictures which refer to the I picture. Further, in the caseof a video signal hierarchically encoded in a time domain, MFUs in anextended layer depend on an MFU of a base layer. Therefore,dependency_counter of the MFU of the base layer indicates a number ofMFUs of the extended layer. It is difficult to generate this field ifthe number of depending MFUs has not been determined.

item_iD indicates an identifier for uniquely specifying an item.

[Non-MP4 Support Model]

As described with reference to FIGS. 19 and 21, a method of thetransmitting device for transmitting an MPU according to MMT includes amethod for transmitting MPU meta data or MF meta data before or aftermedia data or a method for transmitting only media data. Further, areceiving device adopts a method for performing decoding by using anMP4-compliant receiving device or receiving method or a method forperforming decoding without using a header.

The data transmitting method specialized in broadcast stream playbackis, for example, a transmitting method which does not support MP4reconfiguration in the receiving device.

The transmitting method which does not support MP4 reconfiguration inthe receiving device is, for example, a method for not transmitting metadata (MPU meta data and MF meta data) as illustrated in (b) in FIG. 21.In this case, a field value of a fragment type (information indicating adata unit type) included in an MMTP packet is fixed to 2 (=MFU).

In the case where meta data is not transmitted, as described above, theMP4-compliant receiving device has difficulty in decoding received dataas MP4 yet can decode the received data without using meta data(header).

Hence, the meta data is not necessarily indispensable information todecode and play back broadcast streams. Similarly, the information ofthe data unit header of the timed-MFU described with reference to FIG.48 is information for reconfiguring MP4 in the receiving device. MP4does not need to be reconfigured during broadcast stream playback.Therefore, information of the data unit header of the timed-MFU (alsodescribed as a timed-MFU header below) is not necessarily necessaryinformation for broadcast stream playback.

The receiving device can easily reconfigure MP4 by using meta data andinformation for reconfiguring MP4 in a data unit header (suchinformation will be also described as MP4 configuration information).However, the receiving device has difficulty in reconfiguring MP4 evenif only one of meta data and MP4 configuration information in the dataunit header has been transmitted. An advantage provided by transmittingonly one of the meta data and the information for reconfiguring MP4 islittle. Generating and transmitting unnecessary information increaseprocessing and lower transmission efficiency.

Hence, the transmitting device controls transmission of a data structureof MP4 configuration information by using a following method. Thetransmitting device determines whether or not a data unit headerindicates the MP4 configuration information, based on whether or notmeta data is transmitted. More specifically, when the transmittingdevice transmits meta data, the data unit header indicates MP4configuration information, and, when the transmitting device does nottransmit meta data, the data unit header does not indicate the MP4configuration information.

For a method for not indicating the MP4 configuration information in thedata unit header, for example, a following method can be used.

1. The transmitting device sets the MP4 configuration information toreserved and is not operated. Consequently, it is possible to reduce aprocessing amount of a transmission side (the processing amount of thetransmitting device) which generates the MP4 configuration information.

2. The transmitting device deletes the MP4 configuration information,and compresses a header. Consequently, it is possible to reduce theprocessing amount of the transmission side which generates the MP4configuration information, and reduce a transmission quantity.

In addition, when deleting the MP4 configuration information andcompressing the header, the transmitting device may set a flagindicating that the MP4 configuration information has been deleted(compressed). The flag is indicated in the header (an MMTP packetheader, an MMTP payload header or a data unit header) or controlinformation.

Further, information indicating whether or not meta data is transmittedmay be determined in advance or may be additionally signaled in theheader or the control information and transmitted to the receivingdevice.

For example, information indicating whether or not the meta datacorresponding to an MFU is transmitted may be stored in an MFU header.

Meanwhile, the receiving device can determine whether or not the MP4configuration information is indicated, based on whether or not the metadata is transmitted.

In this regard, when a data transmission order (e.g. an order of MPUmeta data, MF meta data, and media data) is determined, the receivingdevice may determine whether or not the MP4 configuration information isindicated, based on whether or not the meta data has been received priorto media data.

When the MP4 configuration information is indicated, the receivingdevice can use the MP4 configuration information to reconfigure MP4.Alternatively, the receiving device can use the MP4 configurationinformation to detect heads of other access units or NAL units.

In addition, the MP4 configuration information may be all or part of atimed-MFU header.

Further, for a non-timed-MFU header, too, the transmitting device maydetermine likewise whether or not the non-timed-MFU header indicatesitemid, based on whether or not the meta data is transmitted.

The transmitting device may determine that only one of the timed-MFU andthe non-timed-MFU indicates the MP4 configuration information. When onlyone of the timed-MFU and the non-timed-MFU indicates the MP4configuration information, the transmitting device determines whether ornot the MP4 configuration information is indicated, based on whether ornot the meta data is transmitted and, in addition, in which one of thetimed-MFU or the non-timed-MFU the MP4 configuration information isindicated. The receiving device can determine whether or not the MP4configuration information is indicated, based on whether or not the metadata is transmitted and a timed/non-timed flag.

In addition, in the above description, the transmitting devicedetermines whether or not MP4 configuration information is indicated,based on whether or not meta data (both of MPU meta data and MF metadata) is transmitted. However, the transmitting device may determine notto indicate the MP4 configuration information when not transmitting partof the meta data (one of the MPU meta data and the MF meta data).

Further, the transmitting device may determine whether or not toindicate the MP4 configuration information based on information otherthan the meta data.

When, for example, a mode such as an MP4 support mode/non-MP4 supportmode is defined, the transmitting device may determine that a data unitheader indicates MP4 configuration information in the case of the MP4support mode, and that the data unit header does not indicate the MP4configuration information in the case of the non-MP4 support mode.Further, the transmitting device may transmit meta data and maydetermine that the data unit header indicates MP4 configurationinformation in the case of the MP4 support mode, and may not transmitmeta data and may determine that the data unit header does not indicatethe MP4 configuration information in the case of the non-MP4 supportmode.

[Flowchart Illustrating Operation of Transmitting Device]

Next, a flowchart illustrating an operation of the transmitting devicewill be described. FIG. 49 illustrates a flowchart illustrating anoperation of the transmitting device.

The transmitting device first determines whether or not to transmit metadata (step S1001). When determining to transmit the meta data (Yes instep S1002), the transmitting device moves to step S1003 to generate MP4configuration information, store the MP4 configuration information in aheader and transmit the MP4 configuration information (step S1003). Inthis case, the transmitting device generates and transmits meta data,too.

Meanwhile, when determining not to transmit the meta data (No in stepS1002), the transmitting device transmits the MP4 configurationinformation without generating the MP4 configuration information andstoring the MP4 configuration information in the header, either (stepS1004). In this case, the transmitting device does not generate andtransmit meta data.

In addition, whether or not to transmit the meta data in step S1001 maybe determined in advance, or may be determined based on whether or notthe meta data has been generated inside the transmitting device or themeta data has been transmitted inside the transmitting device.

[Flowchart Illustrating Operation of Receiving Device]

Next, a flowchart illustrating an operation of the receiving device willbe described. FIG. 50 illustrates a flowchart illustrating an operationof the receiving device.

The receiving device first determines whether or not meta data has beentransmitted (step S1101). It is possible to determine whether or not themeta data is transmitted, by monitoring a fragment type in an MMTPpacket payload. Further, whether or not the meta data is transmitted maybe determined in advance.

When determining that the meta data has been transmitted (Yes in stepS1102), the receiving device reconfigures MP4, and executes decodingprocessing using MP4 configuration information (step S1103). Meanwhile,when determining that the meta data is not transmitted (No in stepS1102), the receiving device executes the decoding processing withoutperforming MP4 reconfiguration processing, and using the MP4configuration information (step S1104).

In addition, the receiving device can detect a random access point,detect an access unit head and detect an NAL unit head by using theabove-described method without using the MP4 configuration information,and can perform decoding processing, packet loss detection and packetloss recovery processing.

For example, an access unit head is head data of an MMT payload whoseaggregation_flag value takes 1. In this case, a Fragmentation_indicatorvalue takes 0.

Further, the head of the slice segment is head data of an MMT payloadwhose aggregation_flag value is 0 and whose fragmentation_indicatorvalue is 00 or 01.

The receiving device can detect the access unit head and detect slicesegments based on the above information.

In addition, the receiving device may analyze an NAL unit header in apacket including the data unit head whose fragmentation_indicator valueis 00 or 01, and detect that an NAL unit type is an AU (access unit)delimiter and the NAL unit type is a slice segment.

[Broadcast Simple Mode]

The method of the receiving device which does not support MP4configuration information has been described as the data transmittingmethod specialized in broadcast stream playback. However, the datatransmitting method specialized in broadcast stream playback is notlimited to this.

As the data transmitting method specialized in broadcast streamplayback, a following method may be used, for example.

-   -   The transmitting device may not use AL-FEC in broadcast fixed        reception environment. When AL-FEC is not used, FEC_type is        fixed to 0 in an MMTP packet header.    -   The transmitting device may use AL-FEC in broadcast mobile        reception environment and a communication UDP (User Datagram        Protocol) transmission mode. When AL-FEC is used, FEC_type in        the MMTP packet header is 0 or 1.    -   The transmitting device may not perform bulk transmission of an        asset. When the bulk transmission of the asset is not performed,        location_infolocation indicating a number of transmission        locations of the asset inside MPT may be fixed to 1.    -   The transmitting device may not perform hybrid transmission of        an assent, a program and a message.

Further, when, for example, the broadcast simple mode is defined, thetransmitting device may use the non-MP4 support mode or use the abovedata transmitting method specialized in broadcast stream playback in thecase of the broadcast simple mode. Whether or not the broadcast simplemode is used may be determined in advance, or the transmitting devicemay store a flag indicating the broadcast simple mode as controlinformation and transmit the control information to the receivingdevice.

Further, based on whether or not the non-MP4 support mode is used, i.e.,whether or not meta data has been transmitted described with referenceto FIG. 49, the transmitting device may use the above data transmittingmethod specialized in broadcast stream playback for the broadcast simplemode in the case of the non-MP4 support mode.

In the case of the broadcast simple mode, the receiving device candetermine that the non-MP4 support mode is used and perform decodingprocessing without reconfiguring MP4.

Further, in the case of the broadcast simple mode, the receiving devicecan determine that a function specialized in broadcast is used, andperform reception processing specialized in broadcast.

Consequently, in the case of the broadcast simple mode, it is possibleto not only reduce processing unnecessary for the transmitting deviceand the receiving device by using the function specialized in broadcastbut also reduce a transmission overhead since unnecessary information isnot compressed and transmitted.

In addition, when the non-MP4 support mode is used, hint informationsupporting an accumulating method other than MP4 configuration may beindicated.

The accumulating method other than the MP4 configuration may include,for example, a method for directly accumulating MMT packets or IPpackets and a method for converting MMT packets into MPEG-2 TS packets.

In addition, in the case of the non-MP4 support mode, a format which isnot compliant with the MP4 configuration may be used.

For example, in the case of the non-MP4 support mode, data may be storedin an MFU in a format with a byte start code not in a format of an MP4format with an NAL unit size added to a head of the NAL unit.

According to MMT, an asset type indicating a type of an asset isdescribed as 4CC registered in MP4REG (http://www.mp4ra.org), and, whenHEVC is used for a video signal, ‘HEV1’ or ‘HVC1’ is used. ‘HEV1’ is aformat which may include a parameter set in a sample, and ‘HVC1’ is aformat which does not include the parameter set in the sample andincludes the parameter set in a sample entry in MPU meta data.

In the case of the broadcast simple mode or the non-MP4 support mode,and in addition, when MPU meta data and MF meta data are nottransmitted, it may be defined that the parameter set is included in thesample. Further, it may be defined that, even when the asset typeindicates any one of ‘HEV1’ and ‘HVC1’, the format of ‘HVC1’ is selectedat all times.

[Supplementary Note 1: Transmitting Device]

As described above, when meta data is not transmitted, the transmittingdevice which sets MP4 configuration information to reserved and is notoperated can be configured as illustrated in FIG. 51, too. FIG. 51 is aview illustrating a specific configuration example of the transmittingdevice.

Transmitting device 300 includes encoder 301, allocator 302 andtransmitter 303. Each of encoder 301, allocator 302 and transmitter 303is realized by, for example, a microcomputer, a processor or a dedicatedcircuit.

Encoder 301 encodes a video signal or an audio signal and generatessample data. The sample data is more specifically a data unit.

Allocator 302 allocates header information including MP4 configurationinformation, to the sample data which is data obtained by encoding thevideo signal or the audio signal. The MP4 configuration information isinformation which is used by a reception side to reconfigure the sampledata as a file of an MP4 format and which has contents differingaccording to whether or not a presentation time of the sample data isdetermined.

As described above, allocator 302 includes the MP4 configurationinformation such as movie_fragment_sequence_number, sample_number,offset, priority and dependency_counter in a header (header information)of a timed-MFU which is an example of the sample data (the sample dataincluding information related to synchronization) whose presentationtime is determined.

Meanwhile, allocator 302 includes the MP4 configuration information suchas item id in the header (header information) of the non-timed-MFU whichis an example of the sample data (the sample data which does not includethe information related to synchronization) whose presentation time isnot determined.

Further, when transmitter 303 does not transmit meta data correspondingto the sample data (in the case of (b) in FIG. 21, for example),allocator 302 allocates header information which does not include theMP4 configuration information, to the sample data according to whetheror not the presentation time of the sample data is determined.

More specifically, allocator 302 allocates the header information whichdoes not include first MP4 configuration, to the sample data when thepresentation time of the sample data is determined, and allocates theheader information including second MP4 configuration information, tothe sample data when the presentation time of the sample data is notdetermined.

For example, as indicated by step S1004 in FIG. 49, when transmitter 303does not transmit the meta data corresponding to the sample data,allocator 302 sets the MP4 configuration information to reserved (fixedvalue) so as not to substantially generate the MP4 configurationinformation and store the MP4 configuration information in a header(header information). In addition, the meta data includes MPU meta dataand movie fragment meta data.

Transmitter 303 transmits the sample data to which the headerinformation is allocated. More specifically, transmitter 303 packetizesthe sample data to which the header information is allocated, accordingto an MMT method, and transmits the sample data.

As described above, according to the transmitting method and thereceiving method specialized in broadcast stream playback, the receivingdevice does not need to reconfigure a data unit to MP4. When thereceiving device does not need to reconfigure the data unit to MP4,unnecessary information such as the MP4 configuration information is notgenerated, so that processing of the transmitting device is reduced.

Meanwhile, the transmitting device needs to transmit necessaryinformation yet needs to secure compliance with the standards such thatextra additional information does not need to be additionallytransmitted.

According to the configuration of transmitting device 300, an area inwhich the MP4 configuration information is stored is fixed to a fixedvalue, so that it is possible to provide an effect that necessaryinformation is transmitted based on the standards without transmittingthe MP4 configuration information, and extra additional information doesnot need to be transmitted. That is, it is possible to reduce theconfiguration of the transmitting device and the processing amount ofthe transmitting device. Further, unnecessary data is not transmitted,so that it is possible to improve transmission efficiency.

[Supplementary Note 2: Receiving Device]

Further, the receiving device which supports transmitting device 300 maybe configured as illustrated in, for example, FIG. 52. FIG. 52 is a viewillustrating another example of a configuration of the receiving device.

Receiving device 400 includes receiver 401 and decoder 402. Receiver 401and decoder 402 are realized by, for example, microcomputers, processorsor dedicated circuits.

Receiver 401 receives sample data which is data obtained by encoding avideo signal or an audio signal, and to which header informationincluding MP4 configuration information for reconfiguring the sampledata as a file of an MP4 format is allocated.

Decoder 402 decodes the sample data without using the MP4 configurationinformation when the receiver does not receive meta data correspondingto the sample data, and when the presentation time of the sample data isdetermined.

For example, as indicated by step S1104 in FIG. 50, decoder 402 executesdecoding processing without using the MP4 configuration information whenreceiver 401 does not receive the meta data corresponding to the sampledata.

Consequently, it is possible to reduce the configuration of receivingdevice 400 and a processing amount of receiving device 400.

Fourth Exemplary Embodiment

[Outline]

In the fourth exemplary embodiment, a method for storing in an MPU anon-timed medium such as a file which does not include informationrelated to synchronization, and a method for transmitting an MMTP packetwill be described. In addition, in the fourth exemplary embodiment, anexample of an MPU according to MMT will be described. However, DASHwhich is based on the same MP4 is also applicable.

First, the method for storing a non-timed medium (also referred to as a“non-timed media data” below) in an MPU will be described in detail withreference to FIG. 53. FIG. 53 is a view illustrating the method forstoring a non-timed medium in an MPU, and a method for transmitting MMTPpackets.

An MPU in which a non-timed medium is stored is configured by ftyp,mmpu, moov and meta boxes, and, in this MPU, information related to afile stored in the MPU is stored. A plurality of idat boxes can bestored in the meta box, and one file can be stored as an item in theidat box.

Part of the ftyp, mmpu, moov and meta boxes configure one data unit asMPU meta data, and the item or the idat box configures a data unit as anMFU.

A data unit is aggregated or fragmented, then is allocated a data unitheader, an MMTP payload header and an MMTP packet header, and istransmitted as an MMTP packet.

In addition, FIG. 53 illustrates an example where File#1 and File#2 arestored in one MPU. MPU meta data is not divided or an MFU is divided andstored in an MMTP packet. However, the MPU and the MFU are not limitedto these, and may be aggregated or fragmented according to a data unitsize. Further, MPU meta data may not be transmitted and, when the MPUmeta data is not transmitted, an MFU is transmitted.

Header information such as a data unit header includes itemID (anidentifier which uniquely specifies an item). An MMTP payload header andan MMTP packet header include a packet sequence number (a sequencenumber of each packet) and an MPU sequence number (a sequence number ofan MPU and a unique number in an asset).

In addition, a data structure of an MMTP payload header and an MMTPpacket header other than a data unit header includes aggregation_flag,fragmentation_indicator, and fragment counter similar to timed media(also referred to as “timed media data” below) described above.

Next, a specific example of header information in the case where a file(=Item=MFU) is divided and packetized will be described with referenceto FIGS. 54 and 55.

FIGS. 54 and 55 are views illustrating examples where each of aplurality of items of divided data obtained by dividing a file ispacketized and is transmitted. More specifically, FIGS. 54 and 55illustrate information (a packet sequence number, a fragment counter, afragmentation indicator, an MPU sequence number and an item ID) includedin one of a data unit header, an MMTP payload header and an MMTP packetheader which is header information per divided MMTP packet. In addition,FIG. 54 is a view illustrating the example where File#1 is divided intoM (M<=256), and FIG. 55 is a view illustrating the example where File#2is divided into N (256<N).

A divided data number indicates an index of head divided data of a file,yet the divided data number information is not transmitted. That is, thedivided data number is not included in header information. Further, thedivided data number is a number allocated to a packet associated witheach of a plurality of items of divided data obtained by dividing afile, and is a number allocated by incrementing the number by 1 from ahead packet in an ascending order.

The packet sequence number is a sequence number of a packet having thesame packet ID. In FIGS. 54 and 55, head divided data of a file is A,and continuous numbers are allocated to the items of divided data up tolast divided data of a file. The packet sequence number is a numberallocated by incrementing the number by 1 from head divided data of thefile in the ascending order, and is a number associated with a divideddata number.

The fragment counter indicates a number of items of a plurality ofdivided data which comes after a plurality of items of these divideddata among a plurality of items of divided data obtained by dividing onefile. Further, the fragment counter indicates a remainder obtained bydividing the number of items of divided data by 256 when the number ofitems of divided data which is the number of a plurality of items ofdivided data obtained by dividing one file exceeds 256. In the examplein FIG. 54, the number of items of divided data is 256 or less, andtherefore a field value of the fragment counter is (M—divided datanumber). Meanwhile, in the example in FIG. 55, the number of items ofdivided data exceeds 256, and therefore takes a remainder obtained bydividing (N—divided data number) by 256 and can be expressed asN—divided data number) % 256. In this regard, % represents a symbol ofan operation indicating a remainder obtained by the division.

In addition, the fragmentation indicator indicates a divided state ofdata stored in an MMTP packet, and is a value indicating head divideddata of divided data units, last divided data, other divided data or oneor more undivided data units. More specifically, the fragmentationindicator indicates “01” in the case of the head divided data, indicates“11” in the case of the last divided data, indicates “10” in the case ofthe rest of items of divided data and indicates “00” in the case of theundivided data units.

In the present exemplary embodiment, a case where, when the number ofitems of divided data exceeds 256, the number of items of divided dataindicates a remainder obtained by dividing the number of items ofdivided data by 256 will be described. However, the number of items ofdivided data is not limited to 256, and may take other numbers(predetermined numbers).

Assume a case where a file is divided as illustrated in FIGS. 54 and 55,conventional header information is allocated to each of a plurality ofitems of divided data obtained by dividing the file, and a plurality ofitems of divided data is transmitted. In this case, a receiving devicedoes not know what divided data number the items of data stored inreceived MMTP packets are in the original file (divided data numbers),and the number of items of divided data of the file or has noinformation which makes it possible to specify divided data numbers andthe number of items of divided data. Therefore, according to aconventional transmitting method, even when an MMTP packet is received,it is difficult to uniquely detect divided data numbers of the items ofdata stored in the received MMTP packets, and the number of items ofdivided data.

When, for example, the number of items of divided data is 256 or less asillustrated in FIG. 54 and that the number of items of divided data is256 or less is known in advance, it is possible to specify divided datanumbers and the number of items of divided data by referring to fragmentcounters. However, when the number of items of divided data is 256 ormore, it is difficult to specify divided data numbers and the number ofitems of divided data.

In addition, when the number of items of divided data of a file islimited to 256 or less, and what is more, a data size which can betransmitted by one packet is x [bytes], a transmittable maximum size ofthe file is limited to x*256 [bytes]. For example, broadcast assumes x=4k [bytes], and, in this case, the transmittable maximum size of the fileis limited to 4 k*256=1M [bytes]. Hence, when a file exceeding 1[Mbytes] needs to be transmitted, the transmitting device has difficultyin limiting the number of items of divided data of the file to 256 orless.

Further, by, for example, referring to a fragmentation indicator, thereceiving device can detect head divided data or last head data of afile. Therefore, by counting a number of MMTP packets until the MMTPpacket including the last divided data of the file is received or byreceiving an MMTP packet including the last divided data of the file,and then combining the fragmentation indicator with a packet sequencenumber, the receiving device can calculate a divided data number or thenumber of items of divided data. Consequently, by combining thefragmentation indicator and the packet sequence number, the transmittingdevice may signal the divided data number and the number of items ofdivided data. However, when starting receiving MMTP packets includingitems of divided data, i.e., the items of divided data which are noteither head divided data of the file or last divided data of the file inthe middle of the file, the receiving device has difficulty inspecifying divided data numbers of the items of divided data, and thenumber of items of divided data. The receiving device can specify thedivided data numbers of the items of divided data, and the number ofdivided data for the first time after receiving an MMTP packet includingthe last divided data of the file.

A following method is used for the phenomenon described with referenceto FIGS. 54 and 55, i.e., the following method is used by the receivingdevice to uniquely specify divided data numbers of items of divided dataof a file, and the number of items of divided data in the middle ofreception of packets including the items of divided data of the file.

First, each divided data number will be described.

As each divided data number, the transmitting device signals a packetsequence number of head divided data of the file (item).

According to a signaling method, the packet sequence number is stored incontrol information for managing the file. More specifically, packetsequence number A of the head divided data of the file in FIGS. 54 and55 is stored in the control information. The receiving device obtains avalue of packet sequence number A from the control information, andcalculates the divided data number from the packet sequence numberindicated in a packet header.

A divided data number of divided data is calculated by subtractingpacket sequence number A of the head divided data from a packet sequencenumber of this divided data.

The control information for managing the file is, for example, an assetmanagement table defined according to ARIB STD-B60. The asset managementtable indicates a file size and version information per file, and isstored in a data transmission message and transmitted. FIG. 56 is a viewillustrating a syntax of a loop per file in the asset management table.

When having difficulty in extending an area of an existing assetmanagement table, the transmitting device may signal a packet sequencenumber by using a 32-bit area which is part of an item_info_byte fieldindicating item information. A flag indicating whether or not a packetsequence number in head divided data of a file (item) is indicated inpart of an area of item_info_byte may be indicated in, for example, areserved_future_use field of control information.

When transmitting a file in the case of data carousel, the transmittingdevice may indicate a plurality of packet sequence numbers or a headpacket sequence number of a file transmitted immediately after aplurality of packet sequence numbers.

A packet sequence number is not limited to a packet sequence number ofhead divided data of a file and needs to be information which links adivided data number of the file and the packet sequence number.

Next, the number of items of divided data will be described.

The transmitting device may define a loop order of each file included inthe asset management table as a file transmission order. Thus, headpacket sequence numbers of two continuous files in the transmissionorder can be learned. Consequently, by subtracting the head packetsequence number of the file transmitted in advance from the head packetsequence number of the file subsequently transmitted, it is possible tospecify the number of items of divided data of the file transmitted inadvance. That is, when, for example, File#1 illustrated in FIG. 54 andFile#2 in FIG. 55 are continuous files in this order, a last packetsequence number of File#1 and a head packet sequence number of File#2are allocated continuous numbers.

Further, by defining a file dividing method, it may be defined to makeit possible to specify the number of items of divided data of a file.When, for example, the number of items of divided data is N, by definingthat each size of items of 1st divided data to (N−1)th divided data is Land a size of Nth divided data is a fraction (item_size-L*(N−1)), thereceiving device can calculate back the number of items of data fromitem_size indicated in the asset management table. In this case, aninteger value obtained by rounding up (item_size/L) is the number ofitems of divided data. In addition, the file dividing method is notlimited to this.

Further, the number of items of divided data may be directly stored inthe asset management table.

By using the above method, the receiving device receives controlinformation, and calculates the number of items of divided data based onthe control information. Further, it is possible to calculate a packetsequence number associated with a divided data number of the file basedon the control information. In addition, when a timing to receivepackets of divided data comes earlier than a timing to receive thecontrol information, a divided data number and the number of items ofdivided data may be calculated at the timing to receive the controlinformation.

In addition, when the transmitting device signals a divided data numberor the number of items of divided data by using the above method, thedivided data number or the number of items of divided data is notspecified based on fragment counters, and therefore the fragmentcounters are unnecessary data. Hence, when signaling information whichmakes it possible to specify a divided data number and the number ofitems of divided data by using the above method in the case oftransmission of a non-timed medium, the transmitting device may notoperate fragment counters or may compress a header. Consequently, it ispossible to reduce processing amounts of the transmitting device and thereceiving device, and improve transmission efficiency, too. That is,when transmitting a non-timed medium, the transmitting device may setfragment counters to reserved (invalidated). More specifically, a valueof the fragment counter may be, for example, a fixed value of “0”.Further, when a non-timed medium is received, fragment counters may beignored.

When a timed medium such as a video or an audio is stored, an MMTPpacket transmission order of the transmitting device and an MMTP packetarrival order of the receiving device match, and packets are notretransmitted. Therefore, when it is not necessary to detect packet lossand reconfigure packets, fragment counters may not be operated. In otherwords, in this case, the fragment counters may be set to reserved(invalidated).

In addition, the receiving device can detect a random access point,detect an access unit head and detect an NAL unit head without usingfragment counters, and can perform decoding processing, packet lossdetection and packet loss recovery processing.

Further, transmission of real-time content such as live broadcastdemands lower delay transmission, and demands that data which has beenencoded is sequentially packetized and transmitted. However, in the caseof the real-time content transmission, general transmitting devices havedifficulty in determining the number of items of divided data duringtransmission of head divided data by using conventional fragmentcounters. Therefore, the general transmitting devices transmit the headdivided data after encoding all data units and determining the number ofitems of divided data, and therefore delay occurs. By contrast withthis, the transmitting device and the receiving device according to thepresent exemplary embodiment can reduce this delay by using the abovemethod and by not operating fragment counters.

FIG. 57 is a flowchart illustrating an operation of specifying divideddata numbers in the receiving device.

The receiving device obtains control information in which fileinformation is described (step S1201). The receiving device determineswhether or not a head packet sequence number of a file is indicated incontrol information (step S1202), and calculates a packet sequencenumber associated with a divided data number of divided data of the file(step S1203) when the head packet sequence number of the file isindicated in the control information (Yes in step S1202). Further, thereceiving device obtains MMTP packets in which items of divided data arestored, and then specifies divided data numbers of the file from thepacket sequence numbers stored in the packet headers of the obtainedMMTP packets (step S1204). Meanwhile, when the head packet sequencenumber of the file is not indicated in the control information (No instep S1202), the receiving device obtains an MMTP packet including lastdivided data of the file, and then specifies a divided data number byusing a fragment indicator stored in a packet header of the obtainedMMTP packet, and the packet sequence number (step S1205).

FIG. 58 is a flowchart illustrating an operation of specifying thenumber of items of divided data in the receiving device.

The receiving device obtains control information in which fileinformation is described (step S1301). The receiving device determineswhether or not the control information includes information which makesit possible to calculate the number of items of divided data (stepS1302), and calculates the number of items of divided data based on theinformation included in the control information (step S1303) whendetermining that the control information includes the information whichmakes it possible to calculate the number of items of divided data (Yesin step S1302). Meanwhile, when determining that it is not possible tocalculate the number of items of divided data (No in step S1302), thereceiving device obtains an MMTP packet including last divided data ofthe file, and then specifies the number of items of divided data byusing a fragment_indicator stored in a packet header of the obtainedMMTP packet, and the packet sequence number (step S1304).

FIG. 59 is a flowchart illustrating an operation of determining whetheror not to operate fragment counters in the transmitting device.

First, the transmitting device determines whether a medium to transmit(also referred to as “media data” below) is a timed medium or anon-timed medium (step S1401).

When a determination result in step S1401 indicates the timed medium(the timed medium in step S1402), the transmitting device determineswhether or not MMTP packet transmission/reception orders match inenvironment in which the timed medium is transmitted and whether or notit is unnecessary to reconfigure packets in the case of packet loss(step S1403). When determining that it is unnecessary to reconfigure thepackets (Yes in step S1403), the transmitting device does not operatefragment counters (step S1404). Meanwhile, when determining that it isnot unnecessary to reconfigure the packets (No in step S1403), thetransmitting device operates the fragment counters (step S1405).

When the determination result in step S1401 indicates the non-timedmedium (the non-timed medium in step S1402), the transmitting devicedetermines whether or not to operate the fragment counters based onwhether or not the divided data numbers and the number of items ofdivided data are signaled by using the above-described method. Morespecifically, when signaling the divided data numbers and the number ofitems of divided data (Yes in step S1406), the transmitting device doesnot operate the fragment counters (step S1404). Meanwhile, when notsignaling the divided data numbers and the number of items of divideddata (No in step S1406), the transmitting device operates the fragmentcounters (step S1405).

In addition, when not operating the fragment counters, the transmittingdevice may set values of the fragment counters to reserved or maycompress a header.

In addition, the transmitting device may determine whether or not tosignal the above-described divided data numbers and number of items ofdivided data, based on whether or not to operate the fragment counters.

In addition, when not operating the fragment counters for the timedmedium, the transmitting device may signal divided data numbers or thenumber of divided data by using the above-described method for thenon-timed medium. In addition, the transmitting device may determine howto operate the timed medium, based on whether or not to operate thefragment counters for the non-timed medium. In this case, thetransmitting device can determine whether or not to operate the fragmentcounters likewise both for the timed medium and the non-timed medium.

Next, a method for specifying the number of items of divided data anddivided data numbers (in the case where fragment counters are used) willbe described. FIG. 60 is a view for explaining a method for specifyingthe number of items of divided data and divided data numbers (in thecase where the fragment counters are used).

As described with reference to FIG. 54, when the number of items ofdivided data is 256 or less and that the number of items of divided datais 256 or less is known in advance, it is possible to specify divideddata numbers and the number of items of divided data by referring to thefragment counters.

When the number of items of divided data of a file is limited to 256 orless, and a data size which can be transmitted by one packet is x[bytes], a transmittable maximum size of the file is limited to x*256[bytes]. For example, broadcast assumes x=4 k [bytes], and, in thiscase, the transmittable maximum size of the file is limited to 4k*256=1M [bytes].

When a file size exceeds a transmittable maximum size of the file, thetransmitting device divides the file in advance such that the sizes ofthe divided files are x*256 [bytes] or less. The transmitting devicehandles each of a plurality of divided files obtained by dividing thefile as one file (item), then divides one file into 256 or less, andstores divided data obtained by further dividing the file in MMTPpackets and transmits the MMTP packets.

In addition, the transmitting device may store information indicatingthat an item is a divided file, the number of divided files and asequence number of each divided file in control information, andtransmit the control information to the receiving device. Further, thetransmitting device may store these pieces of information in the assetmanagement table, or may indicate these pieces of information by usingpart of existing field item_info_byte.

When a received item is one divided file of a plurality of divided filesobtained by dividing one file, the receiving device can specify otherdivided files, and reconfigure the original file. Further, by using thenumber of divided files of the divided files of received controlinformation, indices of the divided files and the fragment counters, thereceiving device can uniquely specify the number of items of divideddata and divided data numbers. Furthermore, it is possible to uniquelyspecify the number of items of divided data and the divided data numberswithout using packet sequence numbers.

In this regard, item_id of each of a plurality of divided files obtainedby dividing one file is desirably the same between each other. Inaddition, when different item_id is allocated, item_id of a head dividedfile may be indicated to uniquely refer to a file from another controlinformation.

Further, a plurality of divided files may belong to the same MPU at alltimes. When a plurality of files is stored in an MPU, files obtained bydividing one file may be stored at all times without storing files ofdifferent types. The receiving device can detect a file update bychecking version information per MPU without checking versioninformation per item.

FIG. 61 is a flowchart illustrating an operation of the transmittingdevice in the case where the fragment counters are used.

First, the transmitting device checks a size of a file to transmit (stepS1501). Next, the transmitting device determines whether or not the filesize exceeds x*256 [bytes] (x indicates a data size which can betransmitted by one packet such as an MTU (Maximum Transmission Unit)size) (step S1502), and divides the file such that sizes of dividedfiles are less than x*256 [bytes] (step S1503) when the file sizeexceeds x*256 [bytes] (Yes in step S1502). Further, the transmittingdevice transmits the divided files as items, stores information relatedto the divided files (information indicating, for example, a dividedfile or a sequence number of the divided file) in control information,and transmits the control information (step S1504). Meanwhile, when thefile size is less than x*256 [bytes] (No in step S1502), thetransmitting device transmits the files as items as usual (step S1505).

FIG. 62 is a flowchart illustrating an operation of the receiving devicein the case where the fragment counters are used.

First, the receiving device obtains and analyzes control informationsuch as the asset management table related to transmission of a file(step S1601). Next, the receiving device determines whether or not adesired item is a divided file (step S1602). When determining that thedesired file is the divided file (Yes in step S1602), the receivingdevice obtains information such as divided files or indices of thedivided files for reconfiguring the file from the control information(step S1603). Further, the receiving device obtains items configuringthe divided files, and reconfigures the original file (step S1604).Meanwhile, when determining that the desired file is not the dividedfile (No in step S1602), the receiving device obtains files as usual(step S1605).

That is, the transmitting device signals a packet sequence number ofhead divided data of the file. Further, the transmitting device signalsinformation which makes it possible to specify the number of items ofdivided data. Alternatively, the transmitting device defines a divisionrule which makes it possible to specify the number of items of divideddata. Further, the transmitting device sets the fragment counters toreserved or compresses a header without operating the fragment counters.

When the packet sequence number of head data of the file is signaled,the receiving device specifies divided data numbers and the number ofitems of divided data from the packet sequence number of the headdivided data of the file and the packet sequence number of the MMTPpacket.

From another viewpoint, the transmitting device divides a file, dividesdata per divided file and transmits the divided files. The transmittingdevice signals information (sequence numbers and a number of times ofdivision) which is used for linking divided files.

The receiving device specifies divided data numbers and the number ofitems of divided data from the fragment counters and sequence numbers ofdivided files.

Consequently, the receiving device can uniquely specify the divided datanumbers or the items of divided data. Further, in the middle ofreception of items of divided data, the receiving device can specifydivided data numbers of the items of divided data, and, consequently,reduce a standby time and reduce a memory, too.

Furthermore, by not operating the fragment counters, the configurationsof the transmitting and receiving devices can reduce processing amountsand improve transmission efficiency.

FIG. 63 is a view illustrating a service configuration in the case wherean identical program is transmitted by a plurality of IP data flows. Inthis example, part of data (video and audio) of a program service ID=2is transmitted by the IP data flows using the MMT method, and data whichhas the same service ID and is different from the part of data istransmitted by IP data flows using an advanced BS data transmittingmethod. In addition, file transmission protocols are also different inthis example yet the same protocol may be used.

The transmitting device multiplexes IP data to guarantee that thereceiving device has all items of data configured by a plurality of IPdata flows by a decoding time.

The receiving device can realize the guaranteed receiver operation byperforming processing based on a decoding time by using the dataconfigured by a plurality of IP data flows.

[Supplementary Note: Transmitting Device and Receiving Device]

As described above, a transmitting device which transmits data withoutoperating fragment counters can be configured as illustrated in FIG. 64,too. Further, a receiving device which receives data without operatingfragment counters can be configured as illustrated in FIG. 65, too. FIG.64 is a view illustrating a specific configuration example of thetransmitting device. FIG. 65 is a view illustrating a specificconfiguration example of the receiving device.

Transmitting device 500 includes divider 501, configuring unit 502 andtransmitter 503. Each of divider 501, configuring unit 502 andtransmitter 503 is realized by, for example, a microcomputer, aprocessor or a dedicated circuit.

Receiving device 600 includes receiver 601, determining unit 602 andconfiguring unit 603. Each of receiver 601, determining unit 602 andconfiguring unit 603 is realized by, for example, a microcomputer, aprocessor or a dedicated circuit.

Each component of transmitting device 500 and receiving device 600 willbe described in detail by explaining a transmitting method and areceiving method.

First, the transmitting method will be described with reference to FIG.66. FIG. 66 is a flowchart illustrating an operation of the transmittingdevice (transmitting method).

First, divider 501 of transmitting device 500 divides data into aplurality of items of divided data (step S1701).

Next, configuring unit 502 of transmitting device 500 configures aplurality of packets by allocating header information to each of aplurality of items of divided data and packetizing the plurality ofitems of divided data (step S1702).

Further, transmitter 503 of transmitting device 500 transmits aplurality of configured packets (step S1703). Transmitter 503 transmitsdivided data information and values of invalidated fragment counters. Inaddition, the divided data information is information for specifyingdivided data numbers and the number of items of divided data. Further,the divided data numbers are numbers indicating what divided data numberthe items of divided data are among a plurality of items of divideddata. The number of items of divided data is the number of items of aplurality divided data.

Consequently, it is possible to reduce a processing amount oftransmitting device 500.

Next, the receiving method will be described with reference to FIG. 67.FIG. 67 is a flowchart illustrating an operation of the receiving device(receiving method).

First, receiver 601 of receiving device 600 receives a plurality ofpackets (step S1801).

Next, determining unit 602 of receiving device 600 determines whether ornot the divided data information has been obtained from a plurality ofreceived packets (step S1802).

Further, when determining unit 602 determines that the divided datainformation has been obtained (Yes in step S1802), configuring unit 603of receiving device 600 configures data from a plurality of receivedpackets without using the values of the fragment counters included inthe header information (step S1803).

Meanwhile, when determining unit 602 determines that the divided datainformation is not obtained (No in step S1802), configuring unit 603 mayconfigure data from a plurality of received packets by using the valuesof the fragment counters included in the header information (stepS1804).

Consequently, it is possible to reduce a processing amount of receivingdevice 600.

Fifth Exemplary Embodiment

[Outline]

A transmitting method of transmitting packets (TLV packets) in the casewhere an NAL unit is stored in an NAL size format in a multiplexinglayer will be described in the fifth exemplary embodiment.

As described in the first exemplary embodiment, there are following twotypes of formats for storing NAL units according to H.264 and H.265 inmultiplexing layers. A first format is a format called a byte streamformat for adding a start code including a specific bit sequence to aportion immediately before an NAL unit header. A second format is aformat called an NAL size format for adding a field indicating an NALunit size. The byte stream format is used for a MPEG-2 system or RTP,and the NAL size format is used for MP4 or DASH or MMT for using MP4.

In the byte stream format, the start code can also be configured bythree bytes, and arbitrary bytes (a byte whose value is 0) can also beadded to the start code.

Meanwhile, in the NAL size format according to general MP4, sizeinformation is indicated by one of one byte, two bytes and four bytes.This size information is indicated in a lengthSizeMinusOne field in anHEVC sample entry. The size information indicates one byte when thefield value takes “0”, indicates two bytes when the field value takes“1” and indicates four bytes when the field value takes “3”.

According to “a media transport method according to MMT for digitalbroadcast” of ARIB STD-B60 standardized in July, 2014, when an NAL unitis stored in a multiplexing layer, if an output of an HEVC encoder is abyte stream, a byte start code is removed, and an NAL unit sizeindicated in byte units by 32 bits (an integer without a sign) is addedas length information to a portion immediately before the NAL unit. Inthis regard, MPU meta data including an HEVC sample entry is nottransmitted, and size information is fixed to 32 bits (four bytes).

Further, according to “a media transport method according to MMT fordigital broadcast” of ARIB STD-B60, a pre-decoding buffer for videosignals in a receiving buffer model which a transmitting device takesinto account during transmission in order to guarantee a bufferingoperation of a receiving device is defined as a CPB (Coded PictureBuffer).

However, the following phenomenon occurs. The CPB in the MPEG-2 systemand an HRD (Hypothetical Reference Decoder) according to HEVC aredefined assuming that video signals have byte stream formats. Hence,when, for example, a rate of transmitting packets is controlled assuminga byte stream format to which 3-byte start code is added, a phenomenonthat a receiving device which has received the transmitting packet of anNAL size format to which a four-byte size area is added has difficultyin satisfying a receiving buffer model according to ARIB STD-B60 islikely to occur. Further, the receiving buffer model according to ARIBSTD-B60 does not indicate a specific buffer size and an extraction rate,and therefore has difficulty in guaranteeing a buffering operation ofthe receiving device.

Hence, a receiving buffer model which guarantees a buffering operationof a receiver is defined as follows to solve the phenomenon as describedabove.

FIG. 68 is a diagram illustrating a receiving buffer model in the casewhere, for example, a broadcast channel is used based on the receivingbuffer model defined according to ARIB STD-B60.

The receiving buffer model includes a TLV packet buffer (first buffer),an IP packet buffer (second buffer), an MMTP buffer (third buffer) and apre-decoding buffer (fourth buffer). In this regard, a dejitter bufferand a buffer for FEC (Forward Error Correction) are not necessary forthe broadcast channel, and therefore are omitted.

The TLV packet buffer receives the TLV packet (transmitting packet) fromthe broadcast channel, converts an IP packet configured by packetheaders (an IP packet header, a full header of a compressed IP packetand a compressed header of a compressed IP packet) of variable lengthsstored in the received TLV packet, and a payload of a variable lengthinto an IP packet (first packet) including an IP packet header of afixed length of an extended header, and outputs the IP packet obtainedby the convention at a fixed bit rate.

The IP packet buffer converts the IP packet into an MMTP packet (secondpacket) including a packer header and a payload of a variable length,and outputs the MMTP packet obtained by the conversion at a fixed bitrate. In this regard, the IP packet buffer may be merged with the MMTPpacket buffer.

The MMTP buffer converts the output MMTP packet into an NAL unit, andoutputs the NAL unit obtained by the conversion at a fixed bit rate.

The pre-decoding buffer sequentially accumulates the output NAL unit,and generates an access unit from a plurality of accumulated NAL units,and outputs the generated access unit to a decoder at a timing of adecoding time corresponding to the access unit.

In the receiving buffer model illustrated in FIG. 68, the MMTP bufferand the pre-decoding buffer other than the TLV packet buffer and the IPpacket buffer at a previous stage take over buffers of the receivingbuffer model according to MPEG-2 TS.

For example, an MMTP buffer (MMTP B1) for a video includes bufferscorresponding to a transport buffer (TB) and a multiplexing buffer (MB)according to MPEG-2 TS. Further, an MMTP buffer (MMTP Bn) for an audioincludes a buffer corresponding to a transport buffer (TB) according toMPEG-2 TS.

A buffer size of the transport buffer takes the same fixed value as thefixed value of MPEG-2 TS. For example, the buffer size is n times (n maybe a decimal or an integer and is 1 or more) as an MTU size.

Further, an MMTP packet size is defined such that an overhead rate ofthe MMTP packet header is lower than an overhead rate of a PES packetheader.

Consequently, extraction rates RX1, RXn and RXs of the transport bufferaccording to MPEG-2 TS are applicable to an extraction rate from thetransport buffer.

Further, a multiplexing buffer size and an extraction rate are an MBsize and RBX1 according to MPEG-2 TS.

In addition to the above receiving buffer model, a following restrictionis placed to solve the above-described phenomenon.

The HRD definition according to HEVC assumes the byte stream format, andMMT adopts an NAL size format for adding a four-byte size area to a headof an NAL unit. Hence, a rate is controlled to satisfy the HRD in theNAL size format during encoding.

That is, a transmitting device controls a rate of a transmitting packetbased on the receiving buffer model and the restriction.

The receiving device can perform a decoding operation without causing anunderflow or an overflow by performing reception processing by using theabove signal.

In this regard, an extraction rate of the TLV packet buffer (a bit rateat which the TLV packet buffer outputs an IP packet) is set by takinginto account a transmission rate after an IP header is extended.

That is, after receiving an input of the TLV packet whose data size is avariable length, removing a TLV header and extending (restoring) the IPheader, the transmitting device takes into account a transmission rateof the IP packet to be output. In other words, the transmitting devicetakes into account a header increase/decrease amount with respect to theinput transmission rate.

More specifically, the data size is the variable length, there is amixture of a packet whose IP header is compressed and a packet whose IPheader is not compressed and an IP header size differs according to apacket type such as IPv4 and IPv6, and therefore a transmission rate ofan IP packet to be output is not uniform. Hence, an average packetlength of a data size of a variable length is determined, and atransmission rate of an IP packet output from the TLV packet isdetermined.

In this case, the transmission rate is determined assuming that an IPheader is compressed to define a maximum transmission rate after an IPheader is extended.

Further, when there is a mixture of packet types of IPv4 and IPv6 orwhen the definition is made without distinguishing a packet type, atransmission rate is determined assuming an IPv6 packet whose headersize is large and whose increase rate after a head is extended is high.

When, for example, S represents an average packet length of the TLVpacket input to the TLV packet buffer, all IP packets stored in the TLVpackets are IPv6 packets and headers are compressed, a maximum outputtransmission rate after the TLV header is removed and the IP header isextended is

input rate×{S/(step S+IPv6 header compression amount)}.

More specifically, when average packet length S of the TLV packet is setbased on

S=0.75×1500 (1500 assumes a maximum MTU size), and

IPv6 header compression amount=TLV header length−IPv6 header length−UDPheader length=3−40−8 holds,

the maximum output transmission rate after the TLV header is removed andthe IP header is extended is

input rate×1.0417≈input rate×1.05.

FIG. 69 is a view illustrating an example where a plurality of dataunits is aggregated and is stored in one payload.

When a data unit is aggregated according to the MMT method, a data unitlength and a data unit header are added to a portion before a data unitas illustrated in FIG. 69.

However, when, for example, a video signal of an NAL size format isstored as one data unit, as illustrated in FIG. 70, there are two fieldsindicating sizes for one data unit, and these are pieces of overlappinginformation. FIG. 70 is a view illustrating an example where a pluralityof data units is aggregated and is stored in one payload, and an examplewhere a video signal of an NAL size format is one data unit. Morespecifically, both of a size area at a head of an NAL size format(referred to a “size area” below) and a data unit length fieldpositioned before a data unit header of an MMTP payload header arefields indicating sizes and are pieces of overlapping information. When,for example, a length of an NAL unit has L bytes, the size areaindicates the L bytes, the data unit length field indicates Lbytes+“size area length” (bytes). Although values indicated by the sizearea and the data unit length field do not completely match, it ispossible to easily calculate the other value from one value, andtherefore these are overlapping values.

When data including data size information inside is stored as a dataunit and a plurality of data units is aggregated and is stored in onepayload, the following phenomenon occurs: pieces of size informationoverlap, and therefore an overhead is great and transmission efficiencyis poor.

Hence, when the transmitting device stores the data including the datasize information inside as a data unit and aggregates and stores aplurality of data units in one payload, the transmitting device maystore a plurality of data units as illustrated in FIGS. 71 and 72.

As illustrated in FIG. 71, there is a case where a data unit lengthwhich is conventionally included is not indicated in an MMTP payloadheader in which an NAL unit including a size area is stored as a dataunit. FIG. 71 is a view illustrating a configuration of a payload of anMMTP packet which does not indicate a data unit length.

Further, as illustrated in FIG. 72, a flag indicating whether or not adata unit length is indicated or information indicating a size arealength may be additionally stored in a header. A location to store theflag or the information indicating the size area length may be indicatedin units of data units such as a data unit header or may be indicated inunits obtained by aggregating a plurality of data units (in packetunits). FIG. 72 is a diagram illustrating an example in an extend areaallocated in packet units. In this regard, the location to store theinformation to be additionally indicated is not limited to this, and theinformation may be stored in an MMTP payload header, an MMTP packetheader and control information.

When a flag indicating whether or not a data unit length is compressedindicates that a data unit length is compressed, the receiving deviceobtains the length information of the size area inside the data unit,and obtains the size area based on the length information of the sizearea and, consequently, can calculate a data unit length by using theobtained length information of the size area and the size area.

According to the above method, the transmitting device can reduce a dataamount and improve transmission efficiency.

In this regard, an overhead may be reduced by reducing the size areainstead of reducing the data unit length. When the size area is reduced,the information indicating whether or not the size area is reduced orinformation indicating the length of the data unit length field may bestored.

In this regard, an MMTP payload header also includes length information.

When an NAL unit including a size area is stored as a data unit, apayload size area in an MMTP payload header may be reducedirrespectively of whether or not data units are aggregated.

Further, even when data which does not include a size area is stored asa data unit, if data units are aggregated and a data unit length isindicated, a payload size area in an MMTP payload header may be reduced.

When a payload size area is reduced, a flag indicating whether or notthe payload size area has been reduced, length information of thereduced size field or length information of a size field which has notbeen reduced may be indicated similar to the above.

FIG. 73 is a flowchart illustrating the operation performed by thereceiving device.

As described above, the transmitting device stores an NAL unit includinga size area as a data unit, and does not indicate a data unit lengthincluded in an MMTP payload header in an MMTP packet.

An example where a flag indicating whether or not a data unit length isindicated or length information of a size area is indicated in an MMTPpacket will be described below.

The receiving device determines whether or not a data unit includes thesize area and the data unit length is reduced, based on informationtransmitted from a transmission side (step S1901).

When it is determined that the data unit length is reduced (Yes in stepS1902), length information of the size area inside the data unit isobtained, the size area inside the data unit is subsequently analyzed,and the data unit length is calculated and obtained (step S1903).

Meanwhile, when it is determined that the data unit length is notreduced (No in step S1902), the data unit length is calculated based onone of the data unit length and the size area inside the data unit asusual (step S1904).

[Supplementary Note: Transmitting Device and Receiving Device]

As described above, the transmitting device which controls a rate tosatisfy the definition of the receiving buffer model during encoding canbe also configured as illustrated in FIG. 74. Further, the receivingdevice which receives and decodes a transmitting packet transmitted fromthe transmitting device can be also configured as illustrated in FIG.75. FIG. 74 is a view illustrating a specific configuration example ofthe transmitting device. FIG. 75 is a view illustrating a specificconfiguration example of the receiving device.

Transmitting device 700 includes generator 701 and transmitter 702.Generator 701 and transmitter 702 are realized by, for example,microcomputers, processors or dedicated circuits.

Receiving device 800 includes receiver 801, first buffer 802, secondbuffer 803, third buffer 804, fourth buffer 805 and decoder 806.Receiver 801, first buffer 802, second buffer 803, third buffer 804,fourth buffer 805 and decoder 806 are realized by, for example,microcomputers, processors or dedicated circuits.

Each component of transmitting device 700 and receiving device 800 willbe described in detail when a transmitting method and a receiving methodwill be described.

First, the transmitting method will be described with reference to FIG.76. FIG. 76 is a flowchart illustrating the operation performed by thetransmitting device (transmitting method).

First, generator 701 of transmitting device 700 generates an encodedstream by controlling a rate to satisfy the predetermined definition ofthe receiving buffer model to guarantee the buffering operation of thereceiving device (step S2001).

Next, transmitter 702 of transmitting device 700 packetizes thegenerated encoded stream, and transmits the transmitting packet obtainedby the packetizing (step S2002).

In this regard, the receiving buffer model used in transmitting device700 employs a configuration including first to fourth buffers 802 to 805which are components of receiving device 800, and therefore will not bedescribed.

Consequently, transmitting device 700 can guarantee a bufferingoperation of receiving device 800 when transmitting data by using amethod such as MMT.

Next, the receiving method will be described with reference to FIG. 77.FIG. 77 is a flowchart illustrating an operation performed by thereceiving device (receiving method).

First, receiver 801 of receiving device 800 receives the transmittingpacket configured by the packet header of variable length and thepayload of variable length (step S2101).

Next, first buffer 802 of receiving device 800 converts a packetconfigured by a packet header of a variable length and a payload of avariable length stored in the received transmitting packet, into a firstpacket including a packet header of a fixed length of an extendedheader, and outputs the first packet obtained by the conversion at afixed bit rate (step S2102).

Next, second buffer 803 of receiving device 800 converts the firstpacket obtained by the conversion into a second packet configured by apacket header and a payload of a variable length, and outputs a secondpacket obtained by the conversion at a fixed bit rate (step S2103).

Next, third buffer 804 of receiving device 800 converts the outputsecond packet into an NAL unit, and outputs the NAL unit obtained by theconversion at a fixed bit rate (step S2104).

Next, fourth buffer 805 of receiving device 800 sequentially accumulatesthe output NAL unit, generates an access unit from a plurality ofaccumulated NAL units, and outputs the generated access unit to adecoder at a timing of a decoding time corresponding to the access unit(step S2105).

Further, decoder 806 of receiving device 800 decodes the access unitoutput from the fourth buffer (step S2106).

Consequently, receiving device 800 can perform a decoding operationwithout causing an underflow or an overflow.

Sixth Exemplary Embodiment

[Outline]

The sixth exemplary embodiment describes a transmitting method and areceiving method in detail using the receiving buffer model described inthe fifth exemplary embodiment.

FIG. 78 is a diagram showing a protocol stack under the MMT/TLV schemedefined according to the ARIB STD-B60.

Under the MMT scheme, in a packet, data such as video and audio isstored per predetermined data units such as media presentation units(MPUs) and media fragment units (MFUs), and an MMTP packet is generatedas a predetermined packet by an attachment of an MMTP packet header tothe packet (MMTP packetization). In addition, by attaching an MMTPpacket header also to control information such as a control messageunder the MMTP, an MMTP packet is generated as a predetermined packet. Afield that stores a 32-bit short-format network time protocol (NTPdefined in IETF RFC 5905) is set for the MMTP packet header and can beused for the QoS control of communication lines or the like.

Moreover, a reference clock of a transmission side (transmitting device)is synchronized with a 64-bit long-format NTP defined in the RFC 5905,and a time stamp such as a presentation time stamp (PTS) and/or a decodetime stamp (DTS) are attached to a synchronized media based on thesynchronized reference clock. In addition, reference clock informationof the transmission side is transmitted to a reception side, and areceiving device generates a system clock based on the reference clockinformation received from the transmission side.

To be specific, the PTS and/or the DTS are stored in an MPU time stampdescriptor or in an MPU extended time stamp descriptor which is MMTPcontrol information. Such PTS and/or DTS are stored in an MP table foreach asset, and then transmitted after having been MMTP packetized as acontrol message.

A UDP header or an IP header is attached to the MMTP packetized data,and is encapsulated into an IP packet. Here, an assembly of the packetshaving, in the IP header or in the UDP header, the same source IPaddress, the same destination IP address, the same source port number,and the same protocol type shall be defined as an IP data flow. Notethat the respective IP packets of the same IP data flow have a redundantheader; therefore, a header is compressed for some of the IP packets.

Furthermore, a 64-bit NTP time stamp is stored into an NTP packet asreference clock information, and then stored into an IP packet. Here, inthe IP packet that stores the NTP packet, the source IP address, thedestination IP address, the source port number, the destination portnumber, and the protocol type are fixed values, and the header of the IPpacket is not compressed.

FIG. 79 is a diagram showing a structure of a TLV packet.

As shown in FIG. 79, a TLV packet can include, as data, an IP packet, acompressed IP packet, and transfer control information such as anaddress map table (AMT) and a network information table (NIT), and thesedata is identified using an 8-bit data type. In addition, in the TLVpacket, a data length (in byte units) is indicated using a 16-bit fieldand a data value is stored after that. Moreover, the TLV packet has1-byte header information before the data type and the headerinformation is stored into a header area of 4 bytes in total. The TLVpacket is also mapped into a transfer slot under an advanced BS transferscheme, and the mapping information is stored into transmission andmultiplexing configuration control (TMCC) control information.

FIG. 80 is a diagram showing an example of the block diagram of thereceiving device.

First, in receiving device 900, through the decoding by demodulator 902and error correction and so on that are performed onto a broadcastsignal received by tuner 901, the TLV packets are extracted. Then,TLV/IP demultiplexer 903 performs DEMUX processing of the TLV packetsand the IP packets. The DEMUX processing of the TLV packets is performedaccording to the data type of the TLV packet. For example, in the casewhere a TLV packet has an IP packet, a compressed header of a compressedIP packet is restored. An IP demultiplexer performs processing such asan analysis on the headers of the IP packets and the UDP packets, andextracts the MMTP packets and the NTP packets.

NTP clock generator 904 reproduces an NTP clock based on the extractedNTP packets. MMTP demultiplexer 905 performs filtering onto thecomponents such as video and audio and the control information, based ona packet ID stored in the extracted MMTP packet header. A time stampdescriptor stored in an MP table is obtained from control informationobtainer 906, and PTS/DTS calculator 907 calculates a PTS and a DTS foreach access unit. Note that the time stamp descriptor includes both ofan MPU time stamp descriptor and an MPU extended time stamp descriptor.

Access unit reproducer 908 transforms the video, audio, and others thathave been filtered from the MMTP packets into data in units forpresentation. More specifically, the data in units for presentationrefers to NAL units and access units of a video signal, audio frames,presentation units for subtitles, and the like. Decoder/presenter 909decodes and presents an access unit at a time when the PTS and the DTSof the access unit match, based on the reference time information of theNTP clock.

Note that the configuration of the receiving device is not limited tothis.

FIG. 81 illustrates the structure of a transfer slot. The transfer slotis made up of 120 slots per frame. A modulation method is assigned tothe transfer slot in units of 5 slots. In addition, a maximum of 16streams can be transferred in one frame. The information tlv_stream_idfor identifying a TLV stream made up of TLV packet train is stored inTMCC information, so that the information tlv_stream_id stored in a slotcan be identified. The modulation method and a code rate can be changedfor each slot, and when the number of the slots to be used isdetermined, the transfer speed of the TLV stream is uniquely determined.

Next, the following describes the method of defining the size of a TLVpacket buffer according to the receiving buffer model described withreference to FIG. 68 in the fifth exemplary embodiment. Note that theextraction rate described therein is used for extraction rate Rxi of theTLV packet buffer. The description of the receiving buffer model shallbe abbreviated because it is the same as the one described in the fifthexemplary embodiment.

The size of the TLV packet buffer is a value defined as a result of thecalculation using, as a reference, the maximum buffer occupancy assumedin the case where the TLV stream, which is made up of TLV packets eachhaving average packet length S with respect to unit time T and has beeninput at transfer rate Rt, is extracted with extraction rate Rxi. Here,average packet length S is an average value calculated in the case oftransferring packets using all the bandwidths of TLV stream, and is notthe size obtained by averaging the TLV stream bandwidths excluding thebandwidth in which a TLV packet storing a null packet or TLV-SI istransferred. Note that the packet having the largest header compressionand expansion amounts is a packet having the smallest packet size amongvariable-length packets, and the case where the occupancy in the TLVpacket buffer becomes the largest is the case where the packets, eachhaving a minimum packet size, are the most consecutive. The minimumpacket size may be defined as a header amount of the TLV packet bufferor may be defined as the smallest value of a TLV/IP/UDP/MMT header forstoring an MMT packet.

Note that the definition of the size of the TLV packet buffer accordingto the receiving buffer model is, in other words, equivalent to thedefinition of the maximum packet count of the TLV packets to betransferred per unit time. In addition, it can be said that thedefinition of the buffer size restricts the number of consecutivepackets, having a minimum packet size, per unit time.

Note that it is desirable that transfer rate Rt, which is used fordefining the buffer size, of an input TLV stream is based on the maximumtransfer rate assumed in the system. Note also that transfer rate Rtneed not be the maximum transfer rate always. Although the method ofsetting unit time T is arbitrary, it is desirable to take intoconsideration the ease of control on the transmission side for thesetting.

The transmission facility (transmitting device) shall performpacketization so as not to overflow the buffer size that is determinedwith the use of transfer rate Rt for input and extraction rate Rxi, forinstance.

Note that transfer rate Rt used in the calculation of the size of theTLV packet buffer, unit time T, and average packet length S are thevalues serving as calculation references, and do not necessarily intendto define the transmission using these values. The transmission speed ofa TLV stream actually differs depending on the rate of transfer. Thetransfer rate differs according to the number of slots used for transferamong 120 slots, a combination of modulation method and code rate forthe transfer of slots, or the like. Accordingly, the transmissionfacility needs to transmit a TLV stream so as not to cause an overflowin the buffer, whichever transfer rate may be used for the transmission.The TLV stream may be transmitted using any control or any algorithm, inso far as the transmission is achieved without causing an overflow inthe buffer.

Namely, the maximum packet count of the TLV packets to be transferredper unit time may be set according to the transfer rate and may thusvary. By transferring, per unit time, the TLV packets less than or equalto the number of packets corresponding to the transfer rate perpredetermined data unit, the TLV packet buffer may be controlled not tooverflow.

With the buffer mounted based on the buffer size and extraction rate asdescribed above, the receiving device is capable for stable receivingoperations without causing an overflow in the buffer, whichever transferrate may be used for transmission. In other words, the receiving deviceneeds to mount a buffer with the size larger than the maximum bufferoccupancy obtained using transfer rate Rt, average packet length S, andextraction rate Rxi.

Next, the following describes the method of defining a TLV buffer modelsize, which allows the definition of a predetermined maximum TLV packetcount per transfer frame length (unit transfer period).

FIG. 82 illustrates a transfer frame and one TLV stream (TLV packettrain) having specific information tlv_stream_id stored in the transferframe.

In addition, (1) in FIG. 82 illustrates the state in which unit time Tis defined to be a transfer frame length in the case of transmittingtransfer frames at a predetermined transfer rate, in the above-describedmethod of defining a buffer size. The transfer frame length is a sectionin which an average section of average packet length S, the maximum TLVpacket count, or the maximum number of consecutive packets having aminimum packet size is restricted. In the advanced BS transfer scheme(ARIB STD-B44), for example, a transfer frame length is 33.04647/ms.Here, the maximum number of the consecutive packets having a minimumpacket size, which are to be transferred per transfer frame length, isdefined as M.

In this case, in order to transmit a TLV stream so as not to cause anoverflow in the TLV packet buffer, the transmission side (transmittingdevice) may transmit the TLV stream to satisfy the definitions compliantwith the buffer model for generating a TLV stream so that the number ofthe TLV packets to be stored in the TLV stream becomes less than orequal to the maximum packet count in whichever section of sections A, B,and C shown in (1) in FIG. 82, irrespective of transfer frame boundary.Here, the length of respective sections A, B, and C is a transfer framelength. Namely, in this case, the transmission facility (transmittingdevice) may send (transmit), per unit time, the TLV packets less than orequal to a predetermined number (maximum TLV packet count).

In addition, the predetermined number may be a value that is set toprevent the TLV packets having a minimum packet size from beingconsecutive to one another. For example, the predetermined number may bea value calculated in the case of setting, as M, the maximum number ofconsecutive packets having a minimum packet size, as has been describedabove.

Moreover, a maximum packet count per transfer frame, an average packetlength, or the number of consecutive packets having a minimum packetsize may be defined, for example, per predetermined data unit such as atransfer frame unit.

For example, the maximum packet count, the average packet length, or thenumber of consecutive packets having a minimum packet size may bedefined per transfer frame such as section D, E, or F illustrated in (2)in FIG. 82. In other words, the transmission facility (transmittingdevice) may send (transmit), per unit time, for consecutive unittransfer periods (periods in plural transfer frame lengths correspondingto plural transfer frames) being unit time periods which do not overlapwith each other, the TLV packets less than or equal to a predeterminednumber (maximum TLV packet count) by transmitting the transfer frames inthe unit transfer periods. In this case, the TLV packets less than orequal to the predetermined number are stored in a transfer frame unit(i.e., one transfer frame) serving as a predetermined data unit.

Next, the following describes a specific example of the method ofcalculating the size of the TLV packet buffer according to the receivingbuffer model.

Here, in the case of setting, as M, the maximum number of theconsecutive packets having a minimum packet size, which aretransferrable per transfer frame, the maximum number of the consecutivepackets having a minimum packet size in the TLV stream to be actuallytransferred is expressed as 2×M. Note that the maximum consecutivenumber M indicates the same value as the maximum number of theconsecutive packets having a minimum packet size, which aretransferrable per the transfer frame length. In the example illustratedin FIG. 82, in the case where M number of packets in the TLV stream areconsecutive in the latter part of section D and also in the former partof section E, the number of consecutive packets reaches the maximumnumber and a total of (2×M) packets are consecutive. In order for thereceiving device to have the buffer size that can accommodate (2×M)number of packets having a minimum packet size, the receiving deviceneeds the buffer size that is twice as large as that calculated usingthe above-described method in the case of setting, as M, the maximumnumber of the consecutive packets having a minimum packet size, whichare transferrable per transfer frame length.

In other words, by defining the TLV buffer size to be twice as large asor larger than the buffer size calculated using the above-describedmethod in which unit time T is defined to be a transfer frame length,the transmission facility is allowed for transmission so as to satisfythe definitions compliant with the buffer model, even in the case whereeach of the maximum packet count, the average packet length, and thenumber of consecutive packets having a minimum packet size, which isobtained as a result of the calculation in which unit time T is definedto be a transfer frame length, is defined per transfer frame.

As has been described above, by setting the size of a TLV packet bufferand an extraction rate, it is possible to define, per transfer frame, amaximum packet count, an average packet length, or the number ofconsecutive packets having a minimum packet size. Note that the maximumpacket count, the average packet length, and the number of consecutivepackets having a minimum packet size can be calculated using the size ofthe TLV packet buffer, an input rate (transfer rate), the extractionrate, and the minimum packet size.

Therefore, in the case where the size of the TLV packet buffer, theextraction rate, and the minimum packet size are defined, it is possibleto define, per transfer speed (transfer rate) of TLV stream, the maximumpacket count, the average packet length, or the number of consecutivepackets having the minimum packet size, of the packets to be stored in atransfer frame. This enables easy transmission control (packetization ormapping into a transfer frame).

The following describes, with respect to FIG. 83, the transmissionmethod in the case where the size of a TLV packet buffer and a maximumpacket count per transfer frame (or a maximum number of consecutivepackets having a minimum packet size) are defined using the methoddescribed with reference to FIG. 82. FIG. 83 is a flowchart illustratingthe transmission method in the case where the size of the TLV packetbuffer and the maximum packet count per transfer frame are defined.

Note that the flowchart and the description illustrate an example ofstoring a TLV packet into a transfer frame, however, the example shallnot be limited to this case and the same flowchart can be also used inthe case of considering a different storage.

First, the transmitting device starts consideration on the storage, pertransfer frame, of a TLV packet storing an MMT packet.

The transmitting device determines whether or not a TLV packet to bestored in a transfer frame is the TLV packet storing an MMTP packet(actual packet) (S2201).

In the case of determining that the TLV packet is the TLV packet storingan MMTP packet (Yes in S2201), the transmitting device stores the TLVpacket into the transfer frame and increments by 1 the packet count ofthe packets to be stored in the transfer frame (S2202).

On the contrary, in the case of determining that the TLV packet is a TLVpacket storing a packet other than MMTP packet (a NULL packet or a TLVpacket storing TLV-SI) (No in S2201), the transmitting device adds upthe sizes of the TLV packets each storing a packet other than MMTPpacket and increments a packet count by 1 per 1.5 KB (MTU size) (S2203).

Namely, two types of packets are provided for TLV packets: a firsttransfer packet storing an actual packet (MMTP packet) different from aninvalid packet (NULL packet); and a second transfer packet storing aNULL packet. In addition, the maximum value of a predetermined packetsize is defined for the first transfer packet, so that it can be saidthat the second transfer packet is a packet which might have a packetsize surpassing the maximum value of the packet size of the firsttransfer packet. When storing a TLV packet into a transfer frame, in thecase of storing the first transfer packet into the transfer frame, thetransmitting device counts the number of the first transfer packets, asthe first packet count. In the case of storing the second transferpacket into the transfer frame, the transmitting device counts, as thesecond packet count, an integer value obtained by dividing the packetsize of the second transfer packet by the maximum value (1.5 KB) of thepacket size of the first transfer packet. The transmitting device thusstores plural TLV packets into the transfer frame so that a total amountof the first packet count and the second packet count obtained as aresult of the counting is less than or equal to a predetermined number.Note that, to be more precise, the second packet count is an integernumber obtained by adding 1 to a quotient obtained by dividing thepacket size of the second transfer packet by the maximum value of thepacket size of the first transfer packet. For example, in the case wherethe packet size of the second transfer packet is always smaller than themaximum value of the packet size of the first transfer packet, it isneedless to say that the number of the second transfer packets isequivalent to the second packet count.

After Step S2202 or Step S2203, the transmitting device calculates acumulative amount of the TLV packet size in the transfer frame (totalamount of data size) (S2204). In other words, the transmitting devicecalculates a sum of the sizes of the TLV packets stored in one transferframe.

Next, the transmitting device determines whether or not the total datasize calculated in Step S2204 reaches a maximum data size per transferframe (S2205).

In the case where the total data size reaches the maximum data size pertransfer frame (Yes in Step S2205), the transmitting device does notinsert the TLV packet but places a NULL packet and ends the processing.

On the contrary, in the case where the total data size does not reachthe maximum data size per transfer frame (No in Step S2205), thetransmitting device determines whether or not a sum of the first packetcount calculated in Step S2202 and the second packet count calculated inStep S2203 reaches a maximum packet count per transfer frame (i.e.,predetermined number) (S2206).

Then, in the case of determining that the sum of the first packet countand the second packet count reaches the maximum packet count (Yes inStep S2206), the transmitting device completes the storage of the TLVpacket storing an MMTP packet (the first transfer packet), into thetransfer frame, and stores the next TLV packet storing an MMTP packet,into the next transfer frame.

Moreover, the transmitting device stores a packet other than the TLVpacket storing an MMTP packet (the first transfer packet), for example,a TLV packet storing a NULL packet or TLV-SI (the second transferpacket), into the remaining transfer bandwidth in the transfer frame(S2207).

As has been described above, the control for satisfying the definitionof the TLV packet buffer compliant with the receiving buffer model canbe facilitated using the number of packets to be stored in a transferframe, a packet size, the number of bytes storable in a transfer frame,and the maximum number of packets storable in a transfer frame.

In addition, by defining the maximum packet count of the TLV packets tobe stored in a transfer frame, an easy design of the receiving devicecan be achieved. In other words, a buffer, which functions as a TLVpacket buffer, of the receiving device needs to be designed to have asize larger than the maximum buffer occupancy obtained using a transferrate, an average packet length of transfer packets, and an extractionrate.

Note that in the case of defining, per maximum transfer speed (permodulation method, per code rate, or per number of transfer slots inuse) of a TLV stream, a maximum packet count per one TLV stream for eachframe, an average packet length, or the number of consecutive packetshaving a minimum packet size, they may be defined in accordance withother restrictions. For example, the average packet length may berestricted so as not to be equal to or less than the length of TS packet(average of 188 or 187 bytes).

Such restriction allows the number of variable-length packets to be lesscompared to the case of storing fixed-length TS packets, which enableseasy implementation and design of the receiving device.

Note that the data to be input into a TLV packet buffer is defined asone TLV stream having specific information tlv_stream_id, however, itmay be redefined as one IP data flow having specific informationtlv_stream_id, a specific IP address, and a specific UDP port number.

Moreover, in the case of CS in advanced BS/CS broadcasting, plural IPdata flows (services) are stored into one TLV stream. In this case, areceiving buffer model and a maximum packet count per transfer frame canbe defined per service.

[Supplementary Note: Transmitting Device and Receiving Device]

As has been described above, the transmitting device which transmitspredetermined data units in the state in which the definitions compliantwith a receiving buffer model are satisfied may be configured asillustrated in FIG. 84. Each of the predetermined data units storesplural transfer packets, and the definitions are predetermined forguaranteeing the buffering operation of the receiving device. Inaddition, the receiving device which receives the predetermined dataunits may be configured as illustrated in FIG. 85. FIG. 84 illustratesan example of the specific configuration of the transmitting device.FIG. 85 illustrates an example of the specific configuration of thereceiving device.

Transmitting device 1000 includes transmitter 1001. Transmitter 1001 canbe realized, for example, by a micro computer, a processor, a dedicatedcircuit, or the like. Namely, each of the processing units configuringtransmitting device 1000 may be realized by software or hardware.

Receiving device 1100 includes receiver 1101 and buffer 1102. Receiver1101 and buffer 1102 are respectively realized, for example, by a microcomputer, a processor, a dedicated circuit, or the like. Namely, each ofthe processing units configuring receiving device 1100 may be realizedby software or hardware.

Each of the components configuring transmitting device 1000 andreceiving device 1100 will be described in detail in the descriptions ofa transmitting method and a receiving method.

First, the transmitting method will be described with reference to FIG.86. FIG. 86 is a flowchart illustrating the operation performed by thetransmitting device (transmitting method).

The transmitting method is a method for transmitting plural transferpackets in the state in which the definitions compliant with a receivingbuffer model, which are predetermined for guaranteeing the bufferingoperation of receiving device 1100, are satisfied.

First, transmitter 1001 of transmitting device 1000 transmits, per unittime, plural transfer packets less than or equal to a predeterminednumber (S2301).

Note that each of the transfer packets includes a variable-length packetheader and a variable-length payload. In addition, the definitionscompliant with the receiving buffer model specify converting a firstpacket into a second packet and outputting the second packet from abuffer of the receiving device at a predetermined extraction rate. Thefirst packet is included in the transfer packets received and includes avariable-length packet header and a variable-length payload. The secondpacket has a fixed-length packet header that is extended.

With such model, the buffering operation of receiving device 1100 can beguaranteed in the case of data transfer using a scheme such as MMT.

Next, the receiving method will be described with reference to FIG. 87.FIG. 87 is a flowchart illustrating the operation performed by thereceiving device (receiving method).

First, receiver 1101 of receiving device 1100 receives plural transferpackets, each including a variable-length packet header and avariable-length payload (S2401).

Next, buffer 1102 of receiving device 1100 converts the first packetinto the second packet and outputs the second packet at a predeterminedextraction rate (S2402). The first packet is included in the transferpackets received and the second packet has a fixed-length packet headerthat is extended,

Note that the size of a buffer is larger than the maximum bufferoccupancy obtained using a transfer rate of transfer packets, an averagepacket length of transfer packets, and an extraction rate.

With such buffer, receiving device 1100 can process without causing anunderflow or overflow in the buffer.

Other Exemplary Embodiments

A transmitting device, a receiving device, a transmitting method and areceiving method according to the exemplary embodiments have beendescribed above. However, the present disclosure is not limited to theseexemplary embodiments.

Further, each processor included in the transmitting device and thereceiving device according to the exemplary embodiment is typicallyrealized as an LSI which is an integrated circuit including an inputterminal and an output terminal. These circuits may be individuallyrealized as one chip or may be realized as one chip including part orall of the circuits.

Further, each processor to be realized as an integrated circuit havingboth an input terminal and an output terminal is not limited to an LSI,and each processor may be realized as a dedicated circuit or ageneral-purpose processor. An FPGA (Field Programmable Gate Array) whichcan be programmed after an LSI is manufactured or a reconfigurableprocessor which can reconfigure connection or a setting of circuit cellsinside the LSI may be used.

In each of the above exemplary embodiments, each component may beconfigured by dedicated hardware or may be realized by executing asoftware program suitable to each component. Each component may berealized by causing a program executing unit such as a CPU or aprocessor to read a software program recorded on a recording medium suchas a hard disk or a semiconductor memory and execute the softwareprogram.

In other words, the transmitting device and the receiving device eachinclude a processing circuit (processing circuitry), and a storagedevice (step storage) which is electrically connected to the processingcircuit (is accessible from the control circuit). The processing circuitincludes at least one of dedicated hardware and the program executingunit. Further, when the processing circuit includes the programexecuting unit, the storage device stores a software program which isexecuted by the program executing unit. The processing circuit executesthe transmitting method and the receiving method according to theexemplary embodiments by using the storage device.

Further, the present disclosure may be a software program or may be anon-transitory computer-readable recording medium on which the programis recorded. Furthermore, naturally, the program can be distributed viaa transmission medium such as the Internet.

Still further, all numbers used above are exemplary numbers tospecifically describe the present disclosure, and the present disclosureis not limited to the illustrated numbers.

Moreover, division of a functional block in each block diagram is anexample, and a plurality of functional blocks may be realized as onefunctional block, one functional block may be divided into a pluralityof functional blocks or part of functions may be transferred to otherfunctional blocks. Besides, single hardware or software may processfunctions of a plurality of functional blocks including similarfunctions in parallel or by way of time division.

Further, an order to execute the steps included in the abovetransmitting method or receiving method is an exemplary order forspecifically describing the present disclosure, and may be other thanthe above order. Furthermore, part of the above steps may be executed atthe same time as those of (in parallel to) other steps.

Thus, the transmitting device, the receiving device, the transmittingmethod, and the receiving method according to one or more aspects of thepresent disclosure have been described above based on the exemplaryembodiments. However, the present disclosure is not limited to theseexemplary embodiments. The present exemplary embodiments to whichvarious modifications conceivable by a person skilled in the art aremade and aspects of the present disclosure that are made by combiningelements of different exemplary embodiments may also be included withinthe scope of the one or more aspects as long as such aspects do notdepart from the gist of the present disclosure.

Although only some exemplary embodiments of the present disclosure havebeen described in detail above, those skilled in the art will readilyappreciate that many modifications are possible in the exemplaryembodiments without materially departing from the novel teachings andadvantages of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure.

INDUSTRIAL APPLICABILITY

The present disclosure is applicable to an apparatus or a device thatperforms a media transport of data such as video data, audio data, etc.

1-8. (canceled)
 9. A receiving method comprising: receiving a pluralityof transfer packets each including a variable-length packet header and avariable-length payload; converting a first packet into a second packetusing a buffer, the first packet being included in the plurality oftransfer packets received and including a variable-length packet headerand a variable-length payload, the second packet having a fixed-lengthpacket header that is extended; and outputting the second packet fromthe buffer at a predetermined extraction rate, wherein a size of thebuffer is larger than maximum buffer occupancy calculated using atransfer rate of the plurality of transfer packets, an average packetlength of the transfer packets, and the predetermined extraction rate.10. (canceled)
 11. A receiving device comprising: a receiver whichreceives a plurality of transfer packets, each including avariable-length packet header and a variable-length payload; and abuffer which converts a first packet into a second packet and outputsthe second packet at a predetermined extraction rate, the first packetbeing included in the plurality of transfer packets received andincluding a variable-length packet header and a variable-length payload,the second packet having a fixed-length packet header that is extended,wherein a size of the buffer is larger than maximum buffer occupancycalculated using a transfer rate of the plurality of transfer packets,an average packet length of the transfer packets, and the predeterminedextraction rate.